p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

HoboMan: Nov 4, 2010

rjmccall posted:

$30k, per developer per year, that has to be saved in developer productivity solely by using ms sql over postgres. so somewhere around 10%

# ? Jul 18, 2018 21:01

Adbot: ADBOT LOVES YOU

# ? Jun 12, 2024 02:52

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Volte posted:

consider: each maintainer has their own keypair, and the admin can issue 'publishing licenses' to them by signing a document saying as much. conceptually, these could be considered as pseudo-packages in and of themselves, so a package version that has been signed by maintainer A implicitly requires maintainer A's publishing license for that package as a dependency. if the admin wants to revoke maintainer A's publishing ability, then they can publish a revoked version of maintainer A's publishing license. the package manager should no longer accept packages signed by keys that are not licensed to publish, and clients attempting to install packages published without a valid license should be an error. that would even support retroactively revoking publishing access after packages have been published, and those packages would automatically become effectively unsigned.

This is the CA model, something which clearly has had no issues whatsoever so far

# ? Jul 18, 2018 22:30

Volte: Oct 4, 2004; woosh woosh

Suspicious Dish posted:

This is the CA model, something which clearly has had no issues whatsoever so far

if you mean it involves a trusted third party, in this case the trusted third party is NPM itself, and it already is the trusted third party. i'm suggesting to leverage that trust into something useful. i'm not suggesting the package manager be a CA to verify the identity of a user or key (practically, i think you can reasonably consider anyone with 2FA access to the account to be the identity in question). but the package manager can certainly be the authority on which accounts are allowed to do what, and encoding those permissions in signed documents is more like JWT, with the twist being that the token is issued to the server and verified on the client rather than vice versa. it's still basically a form of authentication, but it's the package that has to authenticate with the client instead of the client having to authenticate with the server.

# ? Jul 18, 2018 22:55

Shaggar: Apr 26, 2006

Suspicious Dish posted:

I understand package signing just fine, but people seem to call for it to exist when it would solve very few problems. Debian package signing is a joke.

There are multiple authors that can publish the estest package. How should they manage this?

1. Each maintainer has their own privkey, and the user is supposed to add all of the authors to their system. If so, how are new keys communicated officially if a new maintainer joins?

2. There's a single privkey, and it's shared between all the maintainers on their local hard drives.

3. Set up a shared build infrastructure with a private key stored on the server, and build a system so that only maintainers can publish a release? If so, how do users authenticate with a server? Username/password?

What happens when a key is compromised? Key revocation?

3 is the best way to do it and key compromise should be handled with revocation lists same as it is for any other key.

Like I get it you're a js dev so you're used to bad tools and all, but in the real world all of this is automated so users have very little interaction if any with the build server. You have someone sign off on code review for a revision and that gets built and published.

Of course there can be problems with this process but the goal isn't a perfect system. That's impossible. The goal is to minimize risk and I cannot loving fathom why you are so against this when it would have 100% stopped this specific breach we are discussing.

Do you hate tls as well?

# ? Jul 19, 2018 00:51

Shaggar: Apr 26, 2006

Suspicious Dish posted:

People are laughing because key management is the unsolved problem and what happens in practice is that everyone presses "yes" to the prompt and installs the malware anyway. Debian solves this problem by having shared infrastructure that anybody can use to sign the malware with its key.

Linux package managers being trash isn't a reason not to have better package managers.

Key management is a solved problem, just not with PGP which is why nobody should use PGP.

# ? Jul 19, 2018 00:54

tef: May 30, 2004; -> some l-system crap ->

if only we made the walls one foot higher, that would stop people as the ladders are too short

# ? Jul 19, 2018 01:05

Shaggar: Apr 26, 2006

its not adding a foot to a wall its not making the wall out of tissue paper.

# ? Jul 19, 2018 01:08

tef: May 30, 2004; -> some l-system crap ->

keys would provide end to end resilience in the case of a cache/npm being compromised, but they are the ones who tell you which key is which so

you're kinda hosed

# ? Jul 19, 2018 01:09

Shaggar: Apr 26, 2006

NPM is explicitly not who should be telling people what keys to trust.

# ? Jul 19, 2018 01:10

tef: May 30, 2004; -> some l-system crap ->

*compromises dev account* *adds a new signing key* *signs malware*

package signatures as in signing blank checks

# ? Jul 19, 2018 01:12

Volte: Oct 4, 2004; woosh woosh

tef posted:

keys would provide end to end resilience in the case of a cache/npm being compromised, but they are the ones who tell you which key is which so

you're kinda hosed

ideally the public keys would be published outside of npm and could be audited, and they would be part of the lockfile as well, which would guard against unexpected key changes.

tef posted:

*compromises dev account* *adds a new signing key* *signs malware*

package signatures as in signing blank checks

adding signing keys should be done behind a 2FA gateway, and if they're that compromised, then all is lost anyway

# ? Jul 19, 2018 01:15

Shaggar: Apr 26, 2006

tef posted:

*compromises dev account* *adds a new signing key* *signs malware*

package signatures as in signing blank checks

*signature verification fails because the new signing key doesn't match or isn't valid*

# ? Jul 19, 2018 01:15

Shaggar: Apr 26, 2006

like how do you guys not poo poo yourselves every time you use the internet?

# ? Jul 19, 2018 01:15

tef: May 30, 2004; -> some l-system crap ->

Volte posted:

ideally the public keys would be published outside of npm and could be audited, and they would be part of the lockfile as well, which would guard against unexpected key changes.
adding signing keys should be done behind a 2FA gateway, and if they're that compromised, then all is lost anyway

2fa on publish would also prevent this, without needing to reimplement PGP

# ? Jul 19, 2018 01:17

Shaggar: Apr 26, 2006

then you're trusting NPM to guarantee the file integrity which is ludicrous. and then you're also trusting the file to never be modified outside of NPMs servers which is equally ludicrous.

# ? Jul 19, 2018 01:19

tef: May 30, 2004; -> some l-system crap ->

Shaggar posted:

*signature verification fails because the new signing key doesn't match or isn't valid*

*dev accidentally checks signing key into repo*

# ? Jul 19, 2018 01:19

Shaggar: Apr 26, 2006

Again, its not about perfect security (but in that scenario you just revoke the key) but about adding another layer of protection.

# ? Jul 19, 2018 01:22

tef: May 30, 2004; -> some l-system crap ->

Shaggar posted:

then you're trusting NPM to guarantee the file integrity which is ludicrous. and then you're also trusting the file to never be modified outside of NPMs servers which is equally ludicrous.

and the js devs signing the package, but hey, who cares what the code does, just as long as it got signed by one of the keys registered to the project, somehow .... and another third party that was somehow more trustworthy to manage which packages map to which keys, then making that globally available and cached everywhere

# ? Jul 19, 2018 01:23

Shaggar: Apr 26, 2006

JS Dev: Database and disk encryption are pointless because someone can just steal the keys!

# ? Jul 19, 2018 01:23

tef: May 30, 2004; -> some l-system crap ->

Shaggar posted:

Again, its not about perfect security (but in that scenario you just revoke the key) but about adding another layer of protection.

see earlier comment about how 2fa on npm would have prevented this, but, like it wasn't enabled

in this instance, this is the "well why didn't you take backups" school of disaster recovery

the problem is that people lose keys all the goddam time, and it only takes one person to fuckup to break

the effective amount of security it provides is a false confidence that the software hasn't been compromised

# ? Jul 19, 2018 01:25

tef: May 30, 2004; -> some l-system crap ->

Shaggar posted:

JS Dev: Database and disk encryption are pointless because someone can just steal the keys!

MS DEV: so i'm high on a blockchain right now and I swear i won't have to trust anything if i can use enough prime numbers

# ? Jul 19, 2018 01:27

Shaggar: Apr 26, 2006

Even if mfa was enabled on the NPM account, NPM is not trustworthy as a host.
also people don't lose keys all the time thats loving absurd.

# ? Jul 19, 2018 01:29

tef: May 30, 2004; -> some l-system crap ->

i'm not against signing packages it just does very little in the way of inspiring confidence in me

it would work for example, npm itself, signed updates

but with js modules at large, it just takes one smaller module included through a number of indirections for the attack to work

again, this module didn't use 2fa on npm, which handles the problem of credential compromise pretty reasonably

in this instance, the problem is that even if you do have a third party site for verifying keys, well, someone compromised the account and it didn't have 2fa

# ? Jul 19, 2018 01:33

tef: May 30, 2004; -> some l-system crap ->

Shaggar posted:

also people don't lose keys all the time thats loving absurd.

and now, let's check in with bitcoin

# ? Jul 19, 2018 01:35

Ellie Crabcakes: Feb 1, 2008; Stop emailing my boyfriend Gay Crungus

Shaggar posted:

like how do you guys not poo poo yourselves every time you use the internet?

The same way I don't poo poo myself the rest of the time:

# ? Jul 19, 2018 01:35

tef: May 30, 2004; -> some l-system crap ->

you can cryptographically sign what goes into a sewer and validate it on the way out but it's still a pipeline of poo poo

# ? Jul 19, 2018 01:36

Volte: Oct 4, 2004; woosh woosh

signing packages isn't supposed to inspire confidence, it's only supposed to confirm what you would otherwise assume (see: people assuming that the latest release of eslint-scope was not uploaded by a hostile entity). and ideally 2fa would be required to add signing keys.

Volte fucked around with this message at 01:39 on Jul 19, 2018

# ? Jul 19, 2018 01:37

Fiedler: Jun 29, 2002; I, for one, welcome our new mouse overlords.

code signing is useful and good for bits published by large companies. if some code is signed by google, i can pretty much trust that it's not a virus (and that it'll send all of my data back to google, but that's a different matter). in other situations like npm, where it's uniformly poo poo code written by poo poo programmers working for poo poo companies for poo poo pay, a signature is pointless.

# ? Jul 19, 2018 01:39

Volte: Oct 4, 2004; woosh woosh

Signing code has literally nothing to do with whether it's a virus or not. it is not a mark of quality and it says nothing about the trustworthiness of the first party. it just proves that the code was not altered by a third party. even if i'm using joes-form-shitter.js i still want to know if that has been tampered with

# ? Jul 19, 2018 01:42

tef: May 30, 2004; -> some l-system crap ->

there might be ~some~ application of casual cryptography here, but unless it deals with the "who signs the poo poo from the build server" problem it ain't going to solve poo poo

so

let's assume that

a) every developer has a key,
b) somehow we've signed them or have a trusted third party to store every key and name
c) this third party has an entire copy of npm's userbase + project settings i.e who is allowed to publish
d) npm update pulls in every key and confirms that "someone who was meant to sign this, did"

like, almost but again, package signing is about confirming what you get from npm is the same as what was uploaded

which does nothing against the problem of a bad actor using stolen credentials to publish malware

# ? Jul 19, 2018 01:44

tef: May 30, 2004; -> some l-system crap ->

anyway let me know when you've all read up on "the update framework"

# ? Jul 19, 2018 01:45

tef: May 30, 2004; -> some l-system crap ->

Volte posted:

Signing code has literally nothing to do with whether it's a virus or not. it is not a mark of quality and it says nothing about the trustworthiness of the first party. it just proves that the code was not altered by a third party. even if i'm using joes-form-shitter.js i still want to know if that has been tampered with

you could put a little padlock emoji in the console to tell people it's a safe package

# ? Jul 19, 2018 01:46

Fiedler: Jun 29, 2002; I, for one, welcome our new mouse overlords.

Volte posted:

Signing code has literally nothing to do with whether it's a virus or not. it is not a mark of quality and it says nothing about the trustworthiness of the first party. it just proves that the code was not altered by a third party. even if i'm using joes-form-shitter.js i still want to know if that has been tampered with

this is like ordering chinese research chemicals from a spam mail and carefully checking the wrapping to ensure no tampering occurred in transit.

# ? Jul 19, 2018 01:50

Volte: Oct 4, 2004; woosh woosh

it's two separate problems. package signing obviously does not alleviate the problem of bad guys getting the signing keys, but that's a completely different problem than bad guys getting someone's npm credentials. the fact that the latter can cause package integrity breaches is a systemic problem that can be fixed on the NPM side. the problem of bad guys getting the signing keys is a problem that each individual developer and team has to deal with. this isn't a problem that npm can solve. there's literally nothing that npm can do that can't be stymied by poor opsec on the client side, but at least they can harden themselves a little bit by separating npm credentials from package integrity (other than 2fa)

# ? Jul 19, 2018 01:51

tef: May 30, 2004; -> some l-system crap ->

> Signing code has literally nothing to do with whether it's a virus or not.

Yes, it tells you exactly nothing about if it is safe to run code or not

> it just proves that the code was not altered by a third party.

Which is good because this is literally not the problem happening

> Even if i'm using joes-form-shitter.js i still want to know if that has been tampered with

I'm so glad we're reinforcing the walls and keeping the glass door

# ? Jul 19, 2018 01:52

Volte: Oct 4, 2004; woosh woosh

tef posted:

> Signing code has literally nothing to do with whether it's a virus or not.

Yes, it tells you exactly nothing about if it is safe to run code or not

> it just proves that the code was not altered by a third party.

Which is good because this is literally not the problem happening

> Even if i'm using joes-form-shitter.js i still want to know if that has been tampered with

I'm so glad we're reinforcing the walls and keeping the glass door

The literal problem that happened to NPM was a package being tampered with by a third party by having the credentials get scraped out of the npmrc file which probably most npm publishers have on their computer. if package signing was required, then they'd have to also steal the private key, which is a much harder problem and probably not one that you can get by phishing or an automated script. unless the dev has piss-poor op-sec, but then that's on the dev and not NPM. this problem is on NPM

# ? Jul 19, 2018 01:54

tef: May 30, 2004; -> some l-system crap ->

Volte posted:

(other than 2fa)

yep!

# ? Jul 19, 2018 01:54

Volte: Oct 4, 2004; woosh woosh

problems will still happen either way but the blame should always be on the dev for being stupid, not on the package manager for having lovely security practices

# ? Jul 19, 2018 01:56

Volte: Oct 4, 2004; woosh woosh

tef posted:

I'm so glad we're reinforcing the walls and keeping the glass door

The nature of open source is that I can audit the packages I use if I choose. they aren't opaque black boxes although we often treat them that way. i can still figure out if a package is a virus or not, by looking at the source code. if the dev decides to be a shithead and turn the package into a virus, then there's nothing I can do (without auditing every change), but that's more of a condemnation of the concept of trust in general, not against any kind of package signing infrastructure.

# ? Jul 19, 2018 02:04

Adbot: ADBOT LOVES YOU

# ? Jun 12, 2024 02:52

tef: May 30, 2004; -> some l-system crap ->

anyway here's some background reading with threat modelling, and it does use signing too

https://theupdateframework.github.io/publications.html

it's just a hella lot more thought out, but still, like, literally look at bitcoin for how well these ideas in the thread hold up

# ? Jul 19, 2018 02:04

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »