Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)
On Thu, 04 Apr 2024 12:34:42 +0200 Giovanni Biscuolo wrote: > Hello everybody, > > I know for sure that Guix maintainers and developers are working on > this, I'm just asking to find some time to inform and possibly discuss > with users (also in guix-devel) on what measures GNU Guix - the > software distribution - can/should deploy to try to avoid this kind > of attacks. What about integrating ClamAV into the build farms (if this isn't a thing already)? ClamAV could scan source files and freshly-built packages and perhaps detect obvious malware. AFAIK it can also detect CVEs. Guix already has ClamAV packaged so this shouldn't be that hard. -- Jan Wielkiewicz
Re: Should we include nss-certs out of the box?
On Wed, 03 Apr 2024 14:06:37 -0400 Maxim Cournoyer wrote: > Hi, > > It's been Guix policy to let people choose whether to install or not > TLS root certificates and which one to their machine. While I > applaud the idea to have the users make a conscious decision about > it, in practice I suppose very few of us choose to *not* install any > as that basically breaks using web browsers, especially ones like > IceCat which (by default) ensures HTTPS is used on every page. > > It apparently even makes it impossible to run 'guix pull', if I am to > believe bug#62026. > > Should we do as in bug#62026 and have this package be part of the > recommended basic installation? It'd be in the basic set of an > operating-system packages (via its default %base-packages set). It > could still be manipulated via the Guix API (filtered out/replaced > with something else). > > Is anyone opposed to having nss-certs in %base-packages? > Hello, IMO everything should work out of the box. Power users will be able to do their stuff if they need to, so the feature should be opt-out. -- Jan Wielkiewicz
Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)
> Are there other issues (different from the "host cannot execute target > binary") that makes relesase tarballs indispensable for some upstream > projects? i didn't mean to say that tarballs are indispensible. i just wanted to point out that it's not as simple as going through each package definition and robotically changing the source origin from tarball to git repo. it costs some effort, but i don't mean to suggest that it's not worth doing. > So, while "almost all the world" is applying wrong solutions to the > source tarball reproducibility problem, what can Guix do? AFAIU the plan is straightforward: change all package definitions to point to the (git) repos of the upstream, and ignore any generated ./configure scripts if it happens to be checked into the repo. it involves quite some work, both in quantity, and also some thinking around surprises. i think a good first step would be to reword the packaging guidelines in the doc to strongly prefer VCS sources instead of tarballs. > Even if We™ (ehrm) find a solution to the source tarball reproducibility > problem (potentially allowing us to patch all the upstream makefiles > with specific phases in our packages definitions) are we really going to > start our own (or one managed by the reproducible build community) > "reproducible source tarballs" repository? Is this feaseable? but why would that be any better than simply building from git? which, i think, would even take less effort. > > but these generated man files are part of the release tarball, so > > cross compilation works fine using the tarball. > > > AFAIU in this case there is an easy alternative: distribute the > (generated) man files as code tracked in the DVCS (e.g. git) repo > itself. yes, that would work in this case (although, that man page is guaranteed to go stale). my proposal was to simply drop the generated man file. it adds very little value (although it's not zero; web search, etc). -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “It is easy to be conspicuously 'compassionate' if others are being forced to pay the cost.” — Murray N. Rothbard (1926–1995)
Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)
Hi Attila and guix-security team, Attila Lendvai writes: >> Are really "configure scripts containing hundreds of thousands of lines >> of code not present in the upstream VCS" the norm? > > pretty much for all C and C++ projects that use autoconf... which is > numerous, especially among the core GNU components. OK, thank you for the confirmation. [...] >> ...or is it better to completely avoid release tarballs as our sources >> uris? > > yes, and this^ would guarantee the previous point, but it's not always > trivial. > > as an example see this: https://issues.guix.gnu.org/61750 [...] > it breaks crosscompilation, because the host cannot execute the target > binary. OK thanks, I missed that. In general, there is really no other solution for projects than to distribute some artifacts "out of band" or renounce to crosscompile?!? Are there other issues (different from the "host cannot execute target binary") that makes relesase tarballs indispensable for some upstream projects? AFAIU the only thing that /could/ "save" source tarballs it's their /scientific/ reproducibility. In this direction there is a very interesting patchset from Janneke Nieuwenhuizen to try to get a reproducible _Guix_ release tarball: https://issues.guix.gnu.org/70169 «Reproducible `make dist' tarball in defiance of Autotools and Gettext» Obviously having a reproducible tarball makes _practical_ the "pragmatically impossible" task to reproduce a release tarball to check if it corresponds to the same **build** (make dist) performed in the official DVCS repo; only this could "save" all the "build software using release tarball" workflow. ...but /in general/ here we are _downstream_, we have absolutely no control over upstream, and it's _very_ unlikely that we'll see a *good* solution to the tarball reproduciblity problem applied "in the wild upstream" soon. I said "a **good* solution" because some proposals I'm reading about are /bad/ _complications_ that absolutely are NOT really solving the source tarball reproduciblity problem [1]; for example: 1. build the tarball on the RM host using a docker container (unreproducible built) and call it "a reproducible release tarball": https://medium.com/@lanoxx/creating-reproducible-release-tarballs-fa2e2ce745a7 2. have a CI system based on github actions [2] and call it "fully verifiable": https://externals.io/message/122811#122814 (from php.internals mailing list) So, while "almost all the world" is applying _wrong_ solutions to the source tarball reproducibility problem, what can Guix do? Even if We™ (ehrm) find a solution to the source tarball reproducibility problem (potentially allowing us to patch all the upstream makefiles with specific phases in our packages definitions) are we really going to start our own (or one managed by the reproducible build community) "reproducible source tarballs" repository? Is this feaseable? I think there is no solution that can "pragmatically save" the source tarballs of all the software packaged in Guix (and all other distributions part of the reproducible builds effort). > but these generated man files are part of the release tarball, so > cross compilation works fine using the tarball. AFAIU *in this case* there is an easy alternative: distribute the (generated) man files as *code* tracked in the DVCS (e.g. git) repo itself. IMHO it's likely that this workflow can fix most if not all the crosscompilation issues, no? In general, AFAIU it's against reproducibility to distribute pre-generated (compiled? transpiled?) artifacts in a tarball that are not present in the official DVCS repo, especially when tarballs are _not_ reproducible (and they are not in likely 99.9% of cases). > all in all, just by following my gut insctincts, i was advodating for > building everything from git even before the exposure of this > backdoor. in fact, i found it surprising as a guix newbie that not > everything is built from git (or their VCS of choice). Given the current situation so clearly exposed by the "xz backdoor" case, this is something Guix should seriously consider. I mean: Guix should seriously consider to drop source tarballs and _also_ all pre-compiled artifacts distributed only via that tarballs. I don't like this proposal, but I see no other "pragmatically possible" solution. AFAIU no need to rush, but I'm afraid that the class of attacks we can call "supply-chain backdoor injection due to source tarball pragmatically impossible verifiability" are hard to deploy but unfortunately not _too_ hard. [...] Thanks! Gio' [1] this boils down to the unfortunate fact that "reproducibility" is a very misunderstood concept [1.1], even by some very skilled (experienced?) programmers [1.1] because it's strictly related to good _redistribution_ of _trusted_ software, not to good programming [2] https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions#runners «each workflow run executes in a fresh, newly-provisioned
Re: Coordinators for patch review session on Tuesday
On 4 Apr, Christina O'Donnell wrote: > Hi, > > Thanks for your reply, > > > 1. Changing the tag to reviewed-looks-good > > > > It doesn't look like this worked. The way to do this is in the instructions > > are 4. 'Set a user tag' [0], probably the easiest way is to send an email > > (I do get funny results sometimes with my email client): > > > > Subject: setting usertag on 65938 > > > > user guix > > usertag 65938 + reviewed-looks-good > > quit > > > > The first line is important it has to be 'user guix' for it to appear on > > the patch review reports [1]. I think I messed up the instructions in the > > Wiki - you have to have a + in between the bug number and the tag you want > > to set (sorry about that). Please try again. > > Ah I got it this time. I was missing the 'user guix'. I didn't read the wiki > and tried to look it up from the debbugs documentation. > > > This is really just a way of signalling that reviews are happening - so > > trying to keep us in sync. The usertags we're using are: > > > > - patch-review-hackers-list > > - under-review > > - escalated-review-request > > - waiting-on-contributor > > - reviewed-looks-good > If I change the patch quite a lot, should I mark it as > 'escalated-review-request' instead of 'reviewed-looks-good'? Since a maintainer will look at it anyway before it's committed, and you are going to 're-roll' it as a v2 (which they will see) I wouldn't bother. I've been using 'escalated-review-request' for (a) ones I see that are just too hard for me, (b) if I personally think there's some outstanding issue with the patch that I can't solve. > > And should I remove them from the patch-review-hackers-list after I've > responded Yes please - if you remove it from that list, and you make yourself the owner then I hope we'll keep people co-ordinated! > > The patch changes all look reasonable to me, you've already done a lot: > Great, thanks! Good to know I'm doing things vaguely right! > > 1. You should add a reviewed-by trailer: > > Reviews are contributions from our community (and work!) so we should > > recognise them and add trailers. It also helps the maintainer know who did > > the review and therefore the level of confidence. > > > > Basically just add 'Reviewed-by: A Person - [2] > Sure, do you want me resubmit these patches to add that? No - I think you're all good, it looked they were both going to the build system last night. > > It looks like your updated patch retriggered QA, so if you look here and > > the foolow the Data Service link on the right you can see it's building it: > > > >https://qa.guix.gnu.org/issue/65938 > > > > The last step will be for a maintainer to see that it's built correctly, > > see your review and to apply it - great job for a first patch review! > Wonderful! The first of many, I'm hoping. (...) Keep an eye on them in QA, and see if a maintainer sees them. If nothing happens after 10 days consider pinging on IRC. Thanks, Steve
