Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)
On 4/13/24 05:47, Giovanni Biscuolo wrote: > Hello Skyler, > > Skyler Ferris writes: > >> On 4/12/24 23:50, Giovanni Biscuolo wrote: >>> general reminder: please remember the specific scope of this (sub)thread > [...] > >>> (https://yhetil.org/guix/8734s1mn5p@xelera.eu/) >>> >>> ...and if needed read that message again to understand the context, >>> please. >>> >> I assume that this was an indirect response to the email I sent >> previously where I discussed the problems with PGP signatures on release >> files. > No, believe me! I'm sorry I gave you this impression. :-) > >> I believe that this was in scope > To be clear: not only I did not mean to say - even indirectly - that you > where out of scope _or_ that you did not understand the context. > > Also, I really did not mean to /appear/ as the "coordinator" of this > (sub)thread and even less to /appear/ as the one who decides what's in > scope and what's OT; obviously everyone is absolutely free to decide > what is in scope and that she or he understood the context . > >> because of the discussion about whether to use VCS checkouts which >> lack signatures or release tarballs which have signatures. > I still have not commented what you discussed just because I lack time, > not interest; if I can I'll do it ASAP™ :-( > > [...] > > Thanks! Gio' > Thanks for clarifying! Misunderstandings happen sometimes. I look forward to hearing your thoughts if you're able to find time to share them! =)
Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)
Hi all, On 4/11/24 06:49, Andreas Enge wrote: > Am Thu, Apr 11, 2024 at 02:56:24PM +0200 schrieb Ekaitz Zarraga: >> I think it's just better to >> obtain the exact same code that is easy to find > The exact same code as what? Actually I often wonder when looking for > a project and end up with a Github repository how I could distinguish > the "original" from its clones in a VCS. With the signature by the > known (this may also be a wrong assumption, admittedly) maintainer > there is at least some form of assurance of origin. I think this assumption deserves a lot more scrutiny than it typically gets (this is a general statement not particular to your message; even the tails project gets this part of security wrong and they are generally diligent in their efforts). I find it difficult to download PGP keys with any degree of confidence. Often, I see a file with a signature and a key served by the same web page, all coming from the same server. PGP keys are only useful if the attacker compromised the information that the user is receiving from the web page (for example, by gaining control of the web server or compromising the HTTPS session). In the typical scenario I have encountered, the attacker would also replace the key and signature with ones that they generated themself. In short, I'm not sure that we actually get any value from checking the PGP signature for most projects. Either HTTPS is good enough or the attacker won. 99% of the time HTTPS is good enough (though it is notable that the remaining 1% has a disproportionate impact on the affected population). Some caveats: It's difficult for me to use web of trust effectively because I haven't met anyone who uses PGP keys IRL. I'm ultimately trusting my internet connection and servers which are either semi-centralized (there are not that many open keyservers, it's an oligopoly for lack of a better term) or have the problem described above. So maybe everyone else is using web of trust effectively and I don't know what I'm talking about. =) The key download could be compared to the "trust on first use" model that SSH uses. It's not clear to me how effective a simple text box saying "we rotated our keys so you need to re-download it!" would be, but I suspect that most people would download without a second thought. It might be interesting to add public keys and signature locations to package definitions and have Guix re-verify the signature when it downloads the source. This would provide more scrutiny when keys are rotated (because of the review process) and would prevent harm from the situation where the package author is re-downloading the key each time the software is updated. The review process also adds a significant layer of protection because an attacker would need to compromise the HTTPS session of the reviewer in addition to the original package author (assuming that the signature is re-checked by the reviewer; I'm not sure how often this happens in practice). In principle it should be difficult for an attacker to predict who will be reviewing which issue. However, if the pool of reviewers is small it would be easier for the attacker to predict this or just compromise all of the reviewers. Also, if there was some way for the attacker to launch a general attack on people working out of the Guix repository then the value of this protection becomes negligible. The above two paragraphs are somewhat at odds: if Guix has the public key baked in and knows where to download the signature, some reviewers might not double-check the key that they get from the website because Guix is doing it for them. On one hand, I generally think that automating security makes it worse because once it's automated there's a system of rules for attackers to manipulate. On the other hand, if we assume people aren't doing the things they need to then no amount of technical support will give us a secure system. How much is reasonable to expect of people? From my extremely biased perspective, it's difficult to say. >> and everybody is reading. > This is a steep claim! I agree that nobody reads generated files in > a release tarball, but I am not sure how many other files are actually > read. > > Andreas I would guess that the level of the protection is strongly correlated with the popularity of the project among developers who need to add features or fix bugs. I don't think anybody reads a source repository "cover to cover", but we rummage around in the code on an as-needed basis. It would probably be difficult to sneak something into core projects like glibc or gcc, but pretty easy to sneak something into "emojis-but-cooler.js". It would be better to have comprehensive audits of all the projects, but that's not something Guix can manage by itself. It could make it easier to free up resources for that task, but I digress. While it is hyperbolic to say that "with enough eyes, all bugs are shallow" there is a
Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)
Hi again, On 4/12/24 23:50, Giovanni Biscuolo wrote: > Hello, > > general reminder: please remember the specific scope of this (sub)thread > > --8<---cut here---start->8--- > > Please consider that this (sub)thread is _not_ specific to xz-utils but > to the specific attack vector (matrix?) used to inject a backdoor in a > binary during a build phase, in a _very_ stealthy way. > > Also, since Guix _is_ downstream, I'd like this (sub)thread to > concentrate on what *Guix* can/should do to strenghten the build process > /independently/ of what upstreams (or other distributions) can/should > do. > > --8<---cut here---end--->8--- > (https://yhetil.org/guix/8734s1mn5p@xelera.eu/) > > ...and if needed read that message again to understand the context, > please. > > I assume that this was an indirect response to the email I sent previously where I discussed the problems with PGP signatures on release files. I believe that this was in scope because of the discussion about whether to use VCS checkouts which lack signatures or release tarballs which have signatures. If the signatures on the release tarballs are not providing us with additional confidence then we are not losing anything by switching to the VCS checkout. Analysis of the effectiveness of what upstream projects are doing is relevant when trying to determine what we are capable of doing. I also pointed out that a change to Guix such as adding signature metadata to packages could help make up for problems with upstream workflows and how the review process provides additional confidence, demonstrating how this analysis is relevant to what to currently/could possibly do. Please let me know if you think that this is incorrect. Additionally, I need to correct something that I previously said. I stated this: On 4/12/24 17:14, Skyler Ferris wrote: > even the tails project gets this part of security wrong and they are > generally diligent in their efforts Without first double-checking the current state of the project. While this was true at one point, they have since updated their website and clearly explain the problem and what their new verification method is able to protect against at https://tails.net/contribute/design/download_verification/. I apologize for disseminating outdated information.
Re: Handling expensive packages
On 3/12/24 13:45, Peter Polidoro wrote: > If I remember correctly, that was a patch I submitted a couple of years ago > when I was attempting to package some embedded software tools, either the > zephyr west tool or platformio, both written in python. That sent me down the > rabbit hole of dependency updates, the python-mock package being one of them. > > I would still love to have both west and platformio packaged in guix. Perhaps > those exist now in Guix or another channel, I have not checked in a while. If > not, I will attempt to package them again at some point. Thank you for the information. I see that west is packaged in gnu/packages/embedded.scm, but the only reference to platformio is an emacs plugin which I suspect is not what you are referring to. So it sounds like there is no particular reason to process this patch immediately but it makes sense to leave open because it might be used down the line.
Handling expensive packages
Hello, I am looking through the [backlog of open patch submissions](https://issues.guix.gnu.org/search?query=is%3Aopen+tag%3Apatch) to see if any are actionable on my end. One such patch is [issue 55728 which updates python-mock](https://issues.guix.gnu.org/55728). Based on the output of `guix refresh --list-dependent python-mock | wc`, this will impact more than 2000 packages. While this submission is very old, neither the master nor python-team branches have updated this package yet. In [section 22.8.2 "Managing Patches and Branches"](https://guix.gnu.org/en/manual/devel/en/html_node/Managing-Patches-and-Branches.html), there is a recommendation that changes which effect more than 300 dependents are added to a different branch for testing. These dependents presumably still work, as there are not 2000 build failures or a flood of related bug reports. So I think it would make sense to first ask the submitter for their motivation for sending the patch (for example, it might be a prerequisite for a package they want to add and they did not send it as a series for some reason). Depending on their response it might make sense to do something other than apply the update as given (for example, by providing both versions of the package so that a new package can be added without impacting existing branches). But there also might be some reason why it makes sense to apply the update everywhere (for example, if significant optimizations in the update reduces build times for all of the dependent packages). So my main question is whether or not people agree that it makes sense to ask the submitter for more information and take no other action at this time. And as a secondary question, if it does make sense to update the package everywhere is there anything actionable on my end? Regards, Skyler
Re: Guix Days: Patch flow discussion
On 2/6/24 05:39, Steve George wrote: > I agreed to organise some 'patch review' online sessions in the next couple of > weeks. > > Organising a basic process is a good topic for that online session. For > example, elsewhere in the thread someone mentions some tags we could use > consistently so maintainers can find patches that have been reviewed easily. > It > would be great to agree those - try them for a bit - and document them in a > 'howto' so that everyone uses the same process. Have these been announced somewhere yet (eg, with url & exact time)? If not will being subscribed to the help-guix list and/or checking the Guix blog be sufficient to receive notification? As someone who has sent patches in the past and intends to continue sending more in the future, I'd like to do my part to keep the project in a good state. However, I am new to interacting with large FLOSS projects so I'm nervous about causing more problems than I solve if I just start doing things.
Modernizing kmscon
Hello, I am writing to see if the project is interested in using an updated version of kmscon. I ran across this information because I have started using kmscon as the main interface on my Guix machine, and ended up digging into it a bit. I am sending this email only because I think it is polite to offer information upstream, if you are not interested in this then I can keep everything locally without any problems. I am currently keeping the code in a separate repository, but if you are interested in it then I can add it to the Guix repository and send a patch. There are 3 areas I will discuss: the elogind dependency, updating to a more recent Aetf version, and some additional patches I wrote which you may or may not want. # elogind dependency As a result of the work I will discuss below, I noticed that the current version of kmscon does not actually have multi-seat support enabled, which can be seen in the log output on the CI platform (1): Miscellaneous Options: debug: yes (yes: ) optimizations: yes (yes: ) multi-seat: no (no: libsystemd) Although, there is a different line farther up in the file indicating that multi-seat support is desired. I assume that this does not cause any practical issues because a cursory search of the issue tracker doesn't show anyone discussing it. But the substitute* snippets changing the systemd dependency to an elogind dependency imply that someone wanted this at some point, so I'm mentioning it in case it's relevant. I tried building the tip of Aetf's tree with multi-seat support enabled and some changes based on the substitute* snippets. However, there was a fatal error when kmscon called `sd_login_monitor_new`. I don't know why this happened and I didn't look into it because I don't need multi-seat support and I don't have multi-seat equipment in any case. # Aetf version The current kmscon package uses the Aetf repository as the source, with a note that the old one is unmaintained. However, the commit that is specified is from the old repository. This means that Aetf's improvements, such as the ability to select a color palette, are not available. The package definition needs to use the meson-build-system and there are some new or updated dependencies (2). It seems to work on my machine, but currently kmscon is used in the installer where stability is critical so that users have a good first experience. So it might make sense to have a separate kmscon package with the updates and a keep the current package for the installer. I don't know how widely Aetf's version has been used, and it turns out that the automated test suite does very little (there are several files meant for interactive testing, but `meson test` only runs one test which checks some string parsing logic). # Additional patches I have 3 patches implementing 2 changes in my personal fork (3). The first change adds command-line options to set the desired width and height of the viewport. I added this because running kmscon in my VM did not fill the available space. This is implemented across 2 commits, but I could squash them into one patch if you want it. I was careful to preserve existing behavior if these options are not specified so it should not cause any regressions. However, I don't know if you want to keep a patch that adds a feature in your repository. Most of the patches I've seen have been about compatibility with Guix, not adding new features. I did open a pull request with the upstream repository, but I do not think it is maintained any more. The most recent commit is from last year, and there are pull requests more than 6 months old which have not received any reply from the developer. I expect that you will want the other change if you want the updated kmscon. There were some warnings emitted by the current version of meson about deprecated functionality in the build files, I just changed it to conform to the new version. This did not require any functional changes. It just makes the build log a little bit quieter, which is generally a good thing. Sincerely, Skyler (1) http://ci.guix.gnu.org/build/1396560/log/raw (2) https://git.sr.ht/~skyvine/personal-code/tree/c525f74c64b27a793aca088489d7c9cfe7090581/item/src/scheme/guile/guix/packages.scm#L81 (3) https://git.sr.ht/~skyvine/kmscon/log
