71–80 of 178 posts
Earlier quoted context omitted.
all I get is this: > Forbidden > You are not allowed to access this! (yes, with HTML tags on display) :) EDIT: I also found a "I Challenge Thee" page in history. did I just get blocked by antibot measures? why???
Do you have JavaScript disabled? They put one of those anti-scraper things on it.
Earlier quoted context omitted.
> for example the stream of issues from npm et al. Curious, what distros where affected by npm supply chain attacks?
It's npm that's affected, therefore it's not even considered when choosing language/ecosystem for writing distro tools. You'll find no sane distro writing package manager in javascript precisely to avoid this joke of a supply chain.
Here is jujutsu’s list of dependencies[0] and their hashes[1]. As an aside, that’s why I don’t like those packages managers. Something like Python’s numpy or lib curl, get sliced into atomic portions.
[0]: https://github.com/openbsd/ports/blob/master/devel/jujutsu/c...
[1]: https://github.com/openbsd/ports/blob/master/devel/jujutsu/d...
Earlier quoted context omitted.
There was no bug or attack on Debian since 2007 that reproducible packages would prevent. "Well worth it" is not correct. And it just ups the the contribution barrier to Debian higher, I already heard a lot of people complaining that contributing to Debian is hard and while in past I defended it by "they need all the checks and bounds to make sure packages play with eachother nicely", this is just step that makes it…
It makes shipping backdoors a whole lot harder, yes.
Defense in depth obviously is a good thing
I am always surprised Debian are leading this and not the commercial vendors. You'd think big organisations paying for RHEL and Ubuntu would be beating down the door for verifiable binaries.
Earlier quoted context omitted.
Several actually. Pypi is regularly targeted in this way.
But how many of those attackers also had the ability to publish a github commit but didn't to remain more stealthy.
Earlier quoted context omitted.
Reproducible builds are applicable not only to respond to ‘attacks’, a subject you seem to be bikeshedding, but also for other reasons too. Anyone having to maintain a code base or a distributed fleet of devices will gain from this decision, immensely, as their operational periods come and go. Reproducible builds are about longevity as much as they are about security . Please don’t make bold claims about ‘no reason a…
I longevity is harmed though. Your certs need to expire in a few years we think that your toolchain will not be downloadable.
Earlier quoted context omitted.
> for example the stream of issues from npm et al. Curious, what distros where affected by npm supply chain attacks?
It's npm that's affected, therefore it's not even considered when choosing language/ecosystem for writing distro tools. You'll find no sane distro writing package manager in javascript precisely to avoid this joke of a supply chain.
So much time has been wasted on reproducible builds which could have better spent on securing more important parts of Debian. Practically minor changes like a build timestamp being different is not an issue.
What is a win is that two independent parties can run the same build, and get the same binaries.
This is important because it removes trust from builders: anyone can verify their output.
It just so happens that unimportant things like build versions impede that.
Earlier quoted context omitted.
I longevity is harmed though. Your certs need to expire in a few years we think that your toolchain will not be downloadable.
Those problems need to be solved as well.
Debian, like any other legacy distro, mush became declarative, because the '80s model of manual deploy and the absurd pain of D/I and Preseed must end.
They're still a pragmatic choice for many usecases.