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
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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
