3 ms·

Signed packages isn't about just being signed. I could sign anything I like, but that doesn't make it any more secure for you to curl it into /bin/bash. Signa

by TheDong 12y ago

Signed packages isn't about just being signed. I could sign anything I like, but that doesn't make it any more secure for you to curl it into /bin/bash. Signatures are about who signs it, and that's not something mvn has solved at all. Mvn is a free-for-all of binary code that very well could own my system, wheras debian is a curated collection of software which the debian maintainers have signed as being compiled by their systems with no malign influence and having met at least some bar. I'd trust foo.jar signed by debian over foo.jar signed by bobTheJavaBuilder@gmail.com anyday... and mvn only gives you the latter. So yeah, sure, they're signed, but it doesn't actually matter if you don't take the time to hook into the chain of trust (and believe me, mvn does not ask you to trust your transitive jar dependency 50 down the line) or have a trusted third party (debian) do their own validations.

rlpb 12y ago
> wheras debian is a curated collection of software which the debian maintainers have signed as being compiled by their systems with no malign influence and having met at least some bar. And not only that, by shipping the source and requiring that binaries can be built from the source, who signs it is no longer blind trust. Others can audit it. Reproducible builds should improve this even further.
TeMPOraL 12y ago
> wheras debian is a curated collection of software which the debian maintainers have signed as being compiled by their systems with no malign influence and having met at least some bar. This comes with a huge tradeoff, and I guess it's that tradeoff that makes developers like myself opt to sometimes even pipe the cURL to bash. I almost never download any software I actually plan to use through official system repositories, because whatever comes out of apt-get, it's almost always two years behind the last release and missing half the features I need. Sure, I'll apt-get install that libfoo-dev dependency, because I don't care what version it is as long as it's from the last decade. But for any application I actually need to use, it's either git repo or official binary download.
- sre_ops 12y ago
  That's because that those of us who actually run real production systems with real production traffic with real production users who pay real money aren't stupid enough to run a bleeding edge code since we see how many "ooops" bugs are listed in the CHANGELOG
- bandrami 12y ago
  > whatever comes out of apt-get, it's almost always two years behind the last release and missing half the features I need As a sysadmin, I love that, but I've had to come to terms with the fact that some developers have the attention span of hummingbirds who had Cap'n Crunch for breakfast ("two years old" is still very new software from an administration perspective). So, I've basically accepted the fact that whatever stack the developers use I'll build and maintain directly from upstream -- with the price being that the version and extensions/whatever used are frozen from the moment a given project starts.

by TheDong 12y ago

rlpb 12y ago

> wheras debian is a curated collection of software which the debian maintainers have signed as being compiled by their systems with no malign influence and having met at least some bar. And not only that, by shipping the source and requiring that binaries can be built from the source, who signs it is no longer blind trust. Others can audit it. Reproducible builds should improve this even further.

TeMPOraL 12y ago

> wheras debian is a curated collection of software which the debian maintainers have signed as being compiled by their systems with no malign influence and having met at least some bar. This comes with a huge tradeoff, and I guess it's that tradeoff that makes developers like myself opt to sometimes even pipe the cURL to bash. I almost never download any software I actually plan to use through official system repositories, because whatever comes out of apt-get, it's almost always two years behind the last release and missing half the features I need. Sure, I'll apt-get install that libfoo-dev dependency, because I don't care what version it is as long as it's from the last decade. But for any application I actually need to use, it's either git repo or official binary download.

sre_ops 12y ago
That's because that those of us who actually run real production systems with real production traffic with real production users who pay real money aren't stupid enough to run a bleeding edge code since we see how many "ooops" bugs are listed in the CHANGELOG
bandrami 12y ago
> whatever comes out of apt-get, it's almost always two years behind the last release and missing half the features I need As a sysadmin, I love that, but I've had to come to terms with the fact that some developers have the attention span of hummingbirds who had Cap'n Crunch for breakfast ("two years old" is still very new software from an administration perspective). So, I've basically accepted the fact that whatever stack the developers use I'll build and maintain directly from upstream -- with the price being that the version and extensions/whatever used are frozen from the moment a given project starts.