17 Followers
125 Following
268 Posts
GitHubhttps://github.com/maribu/
pronouneshe/him

Heute findet in Magdeburg die erste #pruef demo statt. In Sachsen-Anhalt hat dies besondere Brisanz, weil hier die Machtergreifung einer rechtsextremen Partei im Kontext aktueller Umfragen bei der nächsten Landtagswahl plausibel erscheint.

https://pruef-demos.de/sachsen-anhalt/
https://www.demokrateam.org/aktionen/pruef-sachsen-anhalt/

Sachsen-Anhalt - PRÜF!

AUFTAKTDEMO AM 14.03.!⏰ 14 Uhr📍am blauen Block (SWM/Karstadt)🥁 mit Live-Musik, Comedy, Puppenspiel und mehr! Du hast noch offene Fragen, Anmerkungen oder Lust, beim Aufbau von PRÜF in deinem Bundesland mitzuwirken? Kein Problem, schau gerne in unseren FAQs vorbei oder wende dich an [email protected]. PRÜF-Checkliste [ ] Landtagsbeschluss[ ] Entwurf im Bundesrat eingebracht[x] PRÜF-Demos werden durchgeführt […]

PRÜF!

@bagder IANA just published a new field for the security.txt (RFC 9116) format: "Bug-Bounty: True/False".

The @RIOT_OS team is receiving an increased amount of presumably LLM generated bogus vuln reports (though nowhere near curl levels). And since we deployed a security.txt, scrapers started sending emails inquiring about our bug bounty programs.

I was hoping that if that field gets some visibility, scrapers might filter for that before spamming the security inboxes.

https://www.iana.org/assignments/security-txt-fields/security-txt-fields.xhtml

security.txt Fields

For the problem at hand I ended up doing:

1. Add the release tarball of the dep to the list of sources the package builder downloads and verifies
2. Patch the unpacked dep with the back ported bug fix
3. Patch in an [patch.crates-io] entry into the Cargo.toml to use the patched dep by path
4. Patch the Cargo.lock to match point 3.

That is a bit more involved than I would like, but I think this manageable and maintainable.

Supporting patches directly in [patch.crates-io] would simplify it.

I came up with two approaches:

1. cargo would allow an array of patches to be specified in [patch.crates-io] that it will apply to the crate in the specified order

2. a CLI tool that accepts two+ arguments, the name of the crate to patch as first argument and the patch(es) to apply as arguments two etc.: It would then obtain and verify the source as specified in Cargo.toml, apply the patches, and patch the Cargo.toml to use the prepared and patched folder instead.

To elaborate on why forking is not maintainable: This would either mean that distros would be forced to scale up their git infrastructure, have to manage access for every new fork of a crate, and have to start to review PRs to those forks with the downstream patches. Or they blindly trust that a contributor's fork is well managed, even if that contributor is on vacation. Or have the patch.crates-io point to a random new fork on every patch update.

Compared to diff patches that adds complexity.

Does any rust dev or package maintainer has found a viable approach to downstream patch management? E.g. Arch, Fedora, Alpine and probably most others use diff patches along with the "package recipe", as this allows maintaining everything in one place.

E.g. rust package foo depending on crate bar: If there is a patch for foo, diffs work fine. But what if I need to patch bar? Note that patching in a `[patch.crates-io]` entry is manageable, having that point to a repo is not.

#rustlang #distro

I have written a blog post about the current effort to revamp @RIOT_OS's nanocoap API. I try to analyse what the current state is, how we got there, and a potential vision for the future.

https://mari-bu.de/blog/20260222-nanocoap-api/

Breaking API Changes for nanocoap

RIOT, an open source OS for MCU class IoT devices, supports multiple CoAP implementations, both externally maintained code packaged as well as currently three internal ones. The oldest among them is nanocoap, for which I have proposed a larger set of breaking API changes as a pull request today. tl;dr: User Facing Changes Changes By Example A resource handler that was implemented like this before: static ssize_t _foo_handler(coap_pkt_t *pkt, uint8_t *buf, size_t len, coap_request_ctx_t *context) { static const char *payload = "Hello World"; const size_t payload_len = strlen(payload); // Worst case estimation of the data to add: size_t max_data_len = COAP_OPT_FOO_MAX_LEN + COAP_OPT_BAR_MAX_LEN + COAP_PAYLOAD_MARKER_SIZE + payload_len; ssize_t hdr_len = coap_build_reply(pkt, COAP_CODE_CONTENT, buf, len, max_data_len); if (hdr_len < 0) { return hdr_len; // pass through error } // This step is needed due to an API design flaw hdr_len -= max_data_len; uint8_t *pos = buf + hdr_len; uint16_t lastonum = 0; pos += coap_opt_put_uint(buf, lastonum, COAP_OPT_FOO, 42); lastonum = COAP_OPT_FOO; pos += coap_opt_put_uint(buf, lastonum, COAP_OPT_BAR, 1337); *pos++ = COAP_PAYLOAD_MARKER; memcpy(pos, payload, payload_len); pos += payload_len; return (uintptr_t)pos - (uintptr_t)buf; } Now needs to be implemented like this:

Marian Buschsieweke
Ich bin gerade auf die Doku https://www.zdf.de/video/dokus/zdf-info-100/zdfinfo-2000-meter-bis-andriiwka-100 in der ZDF Mediathek gestoßen. Statt Identitätskontrolle als Implementierung des Jugendschutzes wird das Video nur nachts angezeigt. Wäre das nicht auch eine Option für X, TikTok, Insta und Co? Ich stelle mir vor, dass tagsüber dort dann nur Bernd das Brot als Content verfügbar ist mit Posts wie: "Jetzt bin ich endlich aus der Hölle des KiKa-Sendeschlusses raus. Aber ganz ehrlich, verglichen mit X war die Dauerschleife der Himmel. Mist!"
Amazing! @chrysn attracted with his tutorial about #rust on @RIOT_OS at the #FrOSCon so many people that we had to resort to pair programming to make do with the hardware available.
I'm happy to see such a strong participation in @miri64's @RIOT_OS tutorial at #FrOSCon where the room is packed and all the prepared hardware kits are in use. 🚀 🎉