{"@attributes":{"version":"2.0"},"channel":{"title":"Thomas H\u00fchn on Discoveries","link":"https:\/\/www.thomas-huehn.com\/","description":"Recent content in Thomas H\u00fchn on Discoveries","language":"en","managingEditor":"mail@thomas-huehn.com (Thomas H\u00fchn)","webMaster":"mail@thomas-huehn.com (Thomas H\u00fchn)","lastBuildDate":"Tue, 14 Apr 2026 12:42:36 +0200","item":[{"title":"Answers to questions about upstreaming patches","link":"https:\/\/www.thomas-huehn.com\/answers-upstreaming\/","pubDate":"Tue, 14 Apr 2026 12:42:36 +0200","author":"mail@thomas-huehn.com (Thomas H\u00fchn)","guid":"https:\/\/www.thomas-huehn.com\/answers-upstreaming\/","description":"

Recently I wrote about discussions I’ve experienced about a year ago, where lawyers and open source practitioners wondered what the reporting obligations of the Cyber Resilience Act meant in edge cases.<\/a><\/p>\n

In the meantime the EU has published a draft of a guidance document<\/a> for manufacturers. I had already read it, but did not connect it with the article I wrote in my mind. And it turns out, the EU answers those questions! Let’s see what it says:<\/p>\n

It is not entirely clear whether this means that the security fix itself must be upstreamed, but considering the purpose of the CRA I tend to see it that way.<\/strong><\/p>\n

\n

Furthermore, under Article 13(6) manufacturers that have developed a software\nmodification to address a vulnerability in an integrated component are required to share\nthat software modification (\u2018security fix\u2019) with the person or entity manufacturing or\nmaintaining the component (\u2018sharing upstream\u2019).<\/p>\n<\/blockquote>\n

If you contribute your security fix, do you need to license it? Under the project\u2019s main license? Under a compatible license? At all?<\/strong><\/p>\n

\n

Where the component is a free and open-source component, the security fix should be shared in\na manner compatible with that component\u2019s licence, for example by sharing it under the\nsame licence or under a licence that allows the maintainer to distribute the fix under its\nown licence.<\/p>\n<\/blockquote>\n

If the original project (say, the GitHub project) is gone, what do you do?<\/strong><\/p>\n

\n

\u201cFinally, manufacturers are also not required to report the vulnerability upstream where\nthe component no longer has a maintainer, or when the manufacturer has itself\nduplicated (\u2018forked\u2019) the free and open-source component and no longer relies on the\noriginal maintainer for new versions or security fixes.\u201d<\/p>\n<\/blockquote>\n

If the original project is still there, but looks like it has been inactive for years, is sending a pull request or creating a bugtracker issue enough for CRA compliance?<\/strong><\/p>\n

I’d consider that to fall under the provisions of the previous passage, as well.<\/p>\n

f the project is still there, has been active fairly recently, but never replies or acknowledges your security fix, do you have an obligation to enquire further?<\/strong><\/p>\n

\n

However, manufacturers are not required by the CRA to ensure that their security fixes\nare necessarily accepted by the person or entity manufacturing or maintaining the\ncomponent. Nor are they required to ensure that those fixes are necessarily integrated\ninto the component\u2019s code repository, for instance where the maintainer may prefer a\ndifferent option to fix the issue.<\/p>\n<\/blockquote>\n

Does that make you an Open Source Steward in the sense of the Cyber Resilience Act, with its sundry obligations?<\/strong><\/p>\n

Nothing to find in the guidance, but probably not.<\/p>"},{"title":"Knuth reward check","link":"https:\/\/www.thomas-huehn.com\/knuth-reward-check\/","pubDate":"Sun, 12 Apr 2026 13:09:48 +0200","author":"mail@thomas-huehn.com (Thomas H\u00fchn)","guid":"https:\/\/www.thomas-huehn.com\/knuth-reward-check\/","description":"

It’s been twenty years now that I’ve gotten one of the best letters ever. Donald Knuth confirmed the error I had found in one of his books and sent me the coveted check!<\/a><\/p>\n

Donald Knuth and his reward for any error in one of his books (even typographical ones) are computer science folklore. Preposterous to think that I could possibly earn one! His books have been combed through by thousands and thousands of people. Smarter people than I am. More patient people.<\/p>\n

And then it happened. I thought I had found an error. But I did not report it right away, I waited and re-checked it for months, lest I make a fool of myself. I even told our local genius at university who did not care much and dismissed my excitement.<\/p>\n

See, the error I found is in a very special place. The book is \u201cComputer Modern Typefaces\u201d, so it’s a less read book (not the TeXbook or The Art of Computer Programmming), but still, practically everybody who has given that book a shot will have read over that error.<\/p>\n

Because it’s on page Arabic one. In the first paragraph. The very first word.<\/p>\n

\n<\/figure>\n

That’s why the Memo field says \u201cE1\u201d: Computer Modern Typefaces is Volume E in the Computers & Typesetting series. Page 1.<\/p>\n

\n<\/figure>\n

I have censored the check slightly, because Knuth is afraid someone might do bad things with those numbers, and he hasn’t been handing out real checks for many years now. Today you get a fantasy certificate of a fantasy bank, the Bank of San Serriffe<\/a>.<\/p>\n

But why will you find me there with the entry \u201c0x$1.20\u201d, i.e. decimal $2.88? A few years later I sent in another proposed error, but I was wrong. Knuth actually wrote a few paragraphs why exactly I’m wrong, but because he counted some throwaway sentence in my bug report as a good suggestion, I got another check for $0.32.<\/p>"},{"title":"Upstreaming patches and the Cyber Resilience Act","link":"https:\/\/www.thomas-huehn.com\/upstreaming-patches-and-cra\/","pubDate":"Sat, 11 Apr 2026 13:20:08 +0200","author":"mail@thomas-huehn.com (Thomas H\u00fchn)","guid":"https:\/\/www.thomas-huehn.com\/upstreaming-patches-and-cra\/","description":"

Article 13 (6) in the Cyber Resilience Act requires manufacturers to report security vulnerabilities they find in an Open Source component they use to the upstream project. It also requires them to share \u201crelevant code or documentation\u201d. It is not entirely clear whether this means that the security fix itself must be upstreamed, but considering the purpose of the CRA I tend to see it that way.<\/p>\n

Now that’s all fine when there is a clear \u201cupstream project\u201d and it is still active. Send a patch or a pull request, reply to further questions, done.<\/p>\n

But we can imagine many complications, and nobody really knows what they entail. I’ve seen a room full of lawyers discuss the implications lively.<\/p>\n

If you contribute your security fix, do you need to license it? Under the project’s main license? Under a compatible license? At all?<\/p>\n

And some questions about the project’s state:<\/p>\n