On 2020-12-29 20:59, Chris wrote: > On 2020-12-29 16:46, John-Mark Gurney wrote: >> Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100: >>> |SolarWinds supply chain attack, being able to smuggle a modified file >>> |into a git repo, say an OS's build server, such that the tools don't >>> |know the tree is modified is a real problem... >>> >>> SHA-256 arrives, if you look at the git history. Until then >>> signing a git tag even with SHA-1 is better than being unsealed. >> >> Actually, no it is not. It provides a false sense a security. SHA-1 >> should only be used as a checksum (detecting non-malicous corruption) >> now. >> >> There's a reason I stopped signing (and even removed the historical >> signatures) of the magnet links that I produce for FreeBSD. >> >> This is also why I expanded the snapaid tool to support releases, to >> make it extermely easy to verify signatures: >> https://www.funkthat.com/gitea/jmg/snapaid >> >>> This attack, well, interesting that FreeBSD with so many >>> developers with ssh push hasn't been soiled more often. I am >> >> And that is why it isn't a major problem yet, in that there are >> additional layers of security, both ssh and https that help >> ensure integrity of the repo in transit... >> >>> cautious regarding such, there is a tremendous amount of >>> propaganda against Russia and China going on .. and then who >>> tapped the cables, who has the budget, hmm. I have read one US >>> national security alert report once, and all i could see was >> >> I am well aware of this, and infact, the reason I've been pushing >> for better security like this IS because of the actions of the NSA... >> I used to get lunch on a weekly basis across the street from one >> of the early revealed NSA wiretap rooms. > OK I've been pondering this since last night. If this is a reasonable > concern, and given all that's already gone into coercing git into > something FreeBSD friendly. Is it reasonable to consider putting all > that effort that's already been excreted, and what would need to be > done. To cobble up a FreeBSD version? [tongue-in-cheek] > fuk-git -- FreeBSDUsersCare-git. Sorry. It's a strain. But I needed face-palm; that was: fuc-git. A failed attempt at wit. :-( the rest holds true. > that acronym. > Seriously tho. It wouldn't be that hard to provide sha384(1) at a minimum. > Better; hmac-sha384, or any of a number of other digests. I'm just > thinking that if everyone pitched in, what with all the other work > that's already been done. It'd all get done on a timeline that wouldn't > leave the FreeBSD repo unsafe. > Mind you; much of this is all conceptual. But I just thought (hoped) it > might be worth while. > > --Chris > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Wed Dec 30 2020 - 04:07:54 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:26 UTC