Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

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