While working on the new git signing feature for tumpa-cli I noticed that some of the commits can not be verified. For a moment I freaked out and then thought it must be a problem in my code. But, I could not dig enough. Opus 4.7 helped me to find the eaxct commit in git's history and a reproducer. I reported the issue to the maintainers and they are working on a fix.

\xc2\xa7 aka § was the cause for me.

git 2.43 transcoded the message to UTF-8 BEFORE calling the signer; signer and storage saw the same bytes (c2 a7). git 2.53 hands the signer the RAW bytes (a7) and transcodes only on the way to the commit object (c2 a7). The invariant "bytes fed to gpg.program at sign time equal the bytes a verifier sees when it reads the commit back" is broken.

git config i18n.commitEncoding iso-8859-1 is supposed to be the configuration if we have non UTF-8 characters. But, I never knew about this configuration before I found the bug.

I want to thank my friends in Anthropic for letting me use the tools and techonology to keep building.

One of the major thing at work is XML, due to all things identity. Yes, XML and SAML are very much alive. SWAMID is the identity fedeation for research and higher education in Sweden and edusgain which is the global identify federation around the world connected 80+ pariticipaaant federations connecting over 10k identify and service providers. And these are based on SAML.

In the last few weeks I released two libraries in Rust and then python bindings for the same using pyo3. uppsala is the zero dependency XML library and pyuppsala is the python binding.

Features of uppsala/pyuppsala

• XML 1.0 parsing with full well-formedness checking
• Namespace-aware DOM with tree mutation (create, append, insert, remove, detach)
• XPath 1.0 evaluation (all axes, functions, predicates)
• XSD validation (structures + datatypes, 40+ built-in types, facets, complex types)
• XSD regex pattern matching (Unicode categories, blocks, character class subtraction)
• Imperative XML builder (XmlWriter) for constructing output without a DOM
• Serialization with pretty-printing, compact output, and streaming to files
• Automatic encoding detection for UTF-8 and UTF-16 (LE/BE)

Read the full documentation

bergshamra is the pure Rust XML Security library implementing the W3C XML Digital Signatures (XML-DSig), XML Encryption (XML-Enc), and XML Canonicalization (C14N) specifications. Built entirely on the RustCrypto ecosystem with Uppsala for XML parsing, and pybergshamra is the python binding.

Features of bergshamra/pybergshamra

• XML Digital Signatures — sign and verify (enveloped, enveloping, detached)
• XML Encryption — encrypt and decrypt (element, content, key wrapping, key transport, multi-recipient)
• XML Canonicalization — all 6 W3C C14N variants (inclusive/exclusive, with/without comments, 1.0/1.1) with document-subset filtering via XPath
• X.509 certificate chain — validation with expiry, trust anchors, CRL revocation, chain building
• Post-quantum signatures — ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) with context strings
• EdDSA — Ed25519 signatures (RFC 8032)
• Key agreement — ECDH-ES (P-256/P-384/P-521), X25519, DH-ES (X9.42 finite-field)
• Key derivation — ConcatKDF, HKDF (SHA-256/384/512), PBKDF2
• RSA-OAEP — configurable digest (SHA-1/224/256/384/512), MGF1, and OAEPparams
• HMAC truncation — HMACOutputLength with CVE-2009-0217 minimum length protection
• SAML support — SAML v1.1 AssertionID attribute as default ID, cid: URI scheme for WS-Security MIME references
• CipherReference — resolve encrypted content via URI with XPath and Base64 transforms
• XPath — XPath, XPath Filter 2.0, XPointer for reference processing
• XSLT — identity transform and minimal XSLT for document-subset operations
• OPC Relationship Transform — for Office Open XML signatures (ECMA-376 Part 2)
• Key formats — PEM, DER, PKCS#8 (plain and encrypted), PKCS#12, X.509 (PEM and DER), xmlsec keys.xml, raw symmetric keys
• KeyInfo resolution — KeyName, X509Certificate (multi-cert chain with leaf detection), X509IssuerSerial, RSA/EC/DSA KeyValue, DEREncodedKeyValue, RetrievalMethod, EncryptedKey, KeyInfoReference
• #![forbid(unsafe_code)] across every crate

Supported algorithms

† MD5 and RIPEMD-160 are behind the legacy-algorithms feature flag.

xmlsec test suite compatibility

Bergshamra is tested against the full xmlsec interoperability test suite (1157 test steps across DSig and Enc). These are the same tests used by the xmlsec1 C library, covering test vectors from the W3C, Merlin, Aleksey, IAIK, NIST, and Phaos interop suites.

The 9 DSig failures are GOST algorithm tests (GOST R 34.10-2001, GOST R 34.10-2012-256, GOST R 34.10-2012-512) which require special OS cryptographic libraries not available in the RustCrypto ecosystem.

These are the libraries, you will see the tools/services built on top of these in the coming months hopefully.

replyfast is a Python module to receive and send messages on Signal.

You can install it via

python3 -m pip install replyfast

or

uv pip install replyfast

I have to add Windows builds to CI though.

I have a script to help you to register as a device, and then you can send and receive messages.

I have a demo bot which shows both sending and rreceiving messages, and also how to schedule work following the crontab syntaxt.

    scheduler.register(
        "*/5 * * * *",
        send_disk_usage,
        args=(client,),
        name="disk-usage",
    )

This is all possible due to the presage library written in Rust.

Py (daughter) is now 11 years old, and she spends a lot of time on Scratch, makes beautiful and fun things. But, she thinks she is not a programmer as she is moving blocks and not typing code like us. I had questions for long time about how to move this Scratch generation into programming in general via Python. EktuPy is my probable solution.

In simple words, we have an editor to write code in the left, and a Canvas/stage on the left. You can do all the similar things you do on scratch here, I have a list of examples in the editor.

We use PyScript and thanks to Astral we have both Ruff and ty for LSP/linting support in the editor (using webassembly). The whole code is executing on the browser of the user.

Yesterday I took part in the monthly PyScript Fun call because Nicholas reminded me, had fun to demonstrate it there and watched what others are building.

The first time Py pocked around for 1:30 hours, she gave me 11 bugs, and next for 5 minutes and asked me to get tutorials, she did not want to read the documentation. So, for every example in the editor we have tutorials, not too detailed yet, but good enough to start.

You can create an account and save your programs. You can share them as public from your dashboard, then others can find those in the explorepage and run the code or remix if they want.

I am super nostalgic about one implementation :)

Oh, because I think kids may not have to learn about async programming in this platform, calls like wait() or ask() or play_sound_until_done() or wait_until() are all synchronous for the edtior, and then some AST transformer adds the async/await as needed.

Feel free to try this out, share the link to your kid or teachers/parents you know. Let me know how to improve. I will publish the codebase, a Django application with proper license and hopefully we can make it even better togather.

This project was not possible without all the work done before, including Scratch, or CodeMirror for the edtior, PyScript / PyOdide, the bigger Python community and Claude/Opus4.5 for incredicable TypeScript/Javascript help :)