HEADS UP: FreeBSD src repo transitioning to git this weekend
Chris
bsd-lists at bsdforge.com
Wed Dec 30 05:07:54 UTC 2020
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"
More information about the freebsd-current
mailing list