I wouldn’t trust my phone to store secrets. LG patch it only about twice a year. Even Google only patch their phones once a month. And we have not even started talking about intentional backdoors… So for the same reason I don’t (any more) store GPG keys on my phone, I will not store SSH keys on my phone.
I was wondering, how does the SSH client talk to the phone?
Your phone (at least for iOS) actually has pretty good secret storage. There was a great talk at BlackHat a few years ago about what Apple does: https://www.youtube.com/watch?v=BLGFriOKz6U
Yes, also some Android devices have it too (TEE/SE). The thing is that, if the device has none of these, any app with enough privileges could read your keys… just like on your computer.
I wouldn’t claim my computer to be saver (okay, okay, I actually would) but this “second factor, put all the trust into a corporate controlled, highly connected, often stolen mobile device” doesn’t make anything better.
Smartcard++ It offers the convenience of having the keys on the device, while not having the keys on the device (at least on android - I haven’t found a way to do smartcards on iOS)!
OpenKeychain is what I am using along with k-9 mail and Password Store, the auth api is still wip. I should have specified that I am not doing ssh stuff yet, sorry if I got your hopes up! :D
Isn’t this basically what you’re supposed to be able to do with a YubiKey (i.e. a dedicated “physical key” that isn’t constantly accessible from the internet)? The idea of carrying around my ssh keys on my phone which can easily be stolen or hacked makes me nervous.
You can configure your YubiKey so that it needs a passphrase and will reset itself after a certain number of failed tries. It’s not a bad way to store a private key.
We are currently working on a new license for Kryptonite. For now, the code is released under All Rights Reserved.
That means that right now, I can do nothing with the code. I likely shouldn’t even look at it. Secondly, the bold part (emphasis mine): no, just no. Anything with a custom license is going to end up as a disaster.
curl | sh over HTTPS being insecure is FUD. It is just as secure as .deb/tarball over HTTPS, which for some reason I never hear people complaining about.
As a release engineer, the thing that bugs me the most about ‘curl | bash’ and that I never see mentioned, is that this format of installer almost never has a version number on it. I could run their script to install the thing on my system and make sure everything works. The next day, I can use the same command to install on another system and I don’t know that I got the same script and that the same things will get installed.
Package Managers enforce versioning and checksumming so you know you got the same, expected software.
‘curl | bash’ tells me, “We’re too lazy to package a release. You handle versioning, checksumming, and verification yourself”. And people accept that because they’re too lazy to do those things, too.
This is a good point, curl|sh also doesn’t really have a single answer for “how do i upgrade”.
For some it’s ‘run the same curl|sh again’, for others this may wipe your current installation and data.
Honestly the most ridiculous ones (in terms of rube goldbergness) are the 200 line shell scripts that add a custom apt repo, and then install a heap of dependencies, before installing the main package.
Because declaring dependencies in the package is apparently as hard as giving people instructions about creating a .list file (or providing a release .deb)
“Cargo culting cool-kid bullshit” comes to mind, but I may just be angry.
9
algernonDebian Developer
edited
6 years ago
|
link
There is a huge difference between a deb and curl | sh though, in that I can extract the contents of the deb without running any of the scripts (dpkg-deb -x). It has a well defined format, too. I can easily uninstall it, and so on and so forth.
Figuring out what a random shell script does is not quite the same.
Also read this - https won’t protect you from malicious code. Precise installation steps, or packages one can inspect more easily, are far superior to curl|sh. If someone does not take the effort to explain how to install their software, why should I trust them that they’ll do anything else right?
While someone could do malicious/stupid things in the maintainer scripts of a .deb, I’ve literally never seen that happen.
With a .deb, you can see what files will be installed where, you can extract the contents, and (barring the aforementioned stupidity in maintainer scripts) you can REMOVE the software, cleanly.
With a .sh script, well fuck you, read the whole god damn thing, and then go fetch whatever shit it downloads and examine that too.
With a .deb, you can see what files will be installed where, you can extract the contents, and (barring the aforementioned stupidity in maintainer scripts) you can REMOVE the software, cleanly.
deb files have an embedded shell script that performs installation tasks, called debian/rules that, “fuck you”, you need to read the whole thing.
There’s also all those downgrade attacks that used to be popular.
9
algernonDebian Developer
edited
6 years ago
|
link
deb files have an embedded shell script that performs installation tasks, called debian/rules that, “fuck you”, you need to read the whole thing.
No, they do not. debian/rules is used for building a debian package, not when installing. They can have various scripts that run during installation, but you can extract the contents without running any of those (dpkg-deb -x). So no, you do not have to read the whole thing, if you want to have a look at what it installs and where. You can even list the files, without extracting them.
The same can’t be said about a curl|sh thing.
As for the two links: Both do their thing in the postinst. One can extract the files only, nullifying their malicious behaviour. You can look at the files without running code. With curl|sh, you can’t. You will have to download and read the shell script to figure out where to get the files from.
Point is, I can look at the files without running the postinst. I have the files without any code to run, or look at. Can’t say the same about the shell script. I still have to go through it and download the files separately.
Your choice to insult someone who disagrees with you reflects on you poorly (not to mention it is extremely unlikely to be true).
My bash is excellent, so I decided to audit a few curl | install scripts awhile back.
The first one took over an hour to review - it pulled in quite a few different other scripts from several domains, none of which did anything obviously untowards (although given how many ways there are to hide a subtle backdoor in a shell script I wouldn’t be that confident).
Anything that shrinks the amount of bash code I have to read to audit a package is a win, and in practice deb postinstall scripts are much shorter.
Your choice to insult someone who disagrees with you reflects on you poorly (not to mention it is extremely unlikely to be true).
I think it’s interesting that you find it insulting if someone observes you cannot do something.
Anything that shrinks the amount of bash code I have to read to audit a package is a win, and in practice deb postinstall scripts are much shorter.
You can’t say “well, I looked at less code so it must be more trustworthy” – the code actually has to be shorter. You still have to look at the binaries in the package, or what’s the point?
My mind is boggled that someone thinks there is something about an archive file containing another archive file, with executable scripts at both layers, more trustworthy than an executable script, when they don’t bother reading either.
You observed nothing of the sort; you insinuated, on no basis other than a disagreement, a lack of competence with one of the primary languages used by package maintainers in someone who is one.
You are, again, missing the point. With a package, I have access to all the files, and the scripts. I can look at the files without reading the scripts.
With a curl|sh, I do not have the files, and I have to read the script to get access to the files.
Being able to is one thing, having to is another, and willing to is a third.
You are, again, missing the point. With a package, I have access to all the files, and the scripts. I can look at the files without reading the scripts.
The type slower.
I actually don’t get your point.
I think people trust .deb files more than they trust .sh files, and my point is that there’s no reason to.
If you think there is, then you’re going to have to explain why, and you’re going to have to do better than dpkg-deb -x because that’s a crock of dogshit that tries to make up some cocked up definition for “secure” that has nothing to do with reality: It doesn’t keep more people safe from harm even hypothetically.
With a curl|sh, I do not have the files, and I have to read the script to get access to the files. Being able to is one thing, having to is another, and willing to is a third.
Don’t insult my intelligence: I haven’t done that to you.
You don’t have the files when you do curl -O && dpkg -i either, which is why you don’t do that. Why would you do that, even if the website says to?
Because we’re talking about trust. I trust esl-erlang even though they tell me (basically) to do that, because at the end of the day, I’m not going to audit the binaries in the archive. I’m going to trust their TLS certificate, just like I’ve trusted the one at debian.org.
You don’t want to trust it, yes Virginia, you absolutely need to read the whole fucking thing. Not just the postinst, but also the things in the tarball that you are ignoring.
I think people trust .deb files more than they trust .sh files, and my point is that there’s no reason to.
There actually is. Because with a deb file, it is a lot easier to ignore the script parts, and have a look at the files. Obviously, if you blindly install one, that is in no way more secure than curl|sh - but that’s not what I’m talking about. I’m talking about a way to inspect what it wants to install. With a package (deb, rpm or even a tarball), I can do that. I can download it, and have the files.
With curl|sh, I first have to read the whole script, and then inspect the files.
I hope we can agree that having the files at hand is a better starting point than first having to figure out where and how to get them from. With a shell script, I’d have to do additional reading, which I don’t need to do when facing a package or a tarball.
If you think there is, then you’re going to have to explain why, and you’re going to have to do better than dpkg-deb -x because that’s a crock of dogshit that tries to make up some cocked up definition for “secure” that has nothing to do with reality: It doesn’t keep more people safe from harm even hypothetically.
Well, for one, dpkg-deb -x is not going to run random commands on my system (because it just extracts a tarball, and does not run maintainer scripts). Nor will it put files in random places (because it puts them in a directory I point it at). I’ll have more control over what it does. That is safer than running a random shell script.
And yes, I could read a shell script. But I have better things to waste my time on than read a random script, because people thought that making a tarball is too hard.
I trust deb packages not because they are inherently more secure - they are not. I trust them more, because I have tools to help me inspect their contents. Or, to put it another way: I distrust curl|sh because it has so many disadvantages, and so little gains over even a simple tarball, that I fail to see its appeal. And even worse, the suggestion to pipe a random script into your shell, coming from the developers of a tool aimed at improving security is just… insane. THAT is my problem. If they’d suggest blindly installing a debian package, I’d call that bad practice too. Now, if they provide a repo, or a tarball, that’s a whole different story.
You don’t have the files when you do curl -O && dpkg -i either, which is why you don’t do that. Why would you do that, even if the website says to?
Of course I won’t run dpkg -i. I’ll run dpkg-deb -x foo.deb /tmp/blah, and voila, I have the files without any of the random scripts run. Can you do the same with a curl|sh thing? No. You’d have to read the whole thing, download the files, and then inspect them. With a package, or even a tarball, this is a whole lot easier. There can still be maintainer scripts, but those are typically small. Not to mention, that I won’t have to read any scripts just to be able to look at the binaries.
More secure, safer? Probably not. Easier? Less error prone? Yes. And that is my point. A directly downloadable package is easier to verify.
If they’d suggest curl -O && dpkg -i, I’d call that bad practice too, by the way. Installing random stuff is bad. Having an easy way to inspect random stuff is, therefore, better than also having to read and understand random shell scripts on top of everything else.
Not just the postinst, but also the things in the tarball that you are ignoring.
No, I’m not ignoring. I’m extracting them with dpkg-deb -xprecisely because I want to look at them. And with a debian package, I can do that without having to read a random shell script to even have access to the files.
Obviously, if you blindly install one, that is in no way more secure than curl|sh - but that’s not what I’m talking about
However it’s what I’m talking about.
So thank you for conceding to my point and agreeing with me.
I hope we can agree that having the files at hand is a better starting point than first having to figure out where and how to get them from. With a shell script, I’d have to do additional reading, which I don’t need to do when facing a package or a tarball.
No, I can’t agree with that.
The biggest problem with Debian and Linux is the fact that the tiniest hole can often be exploited into something bigger.
If you’re relying on your ability to read, then you actually need to be able to read, and you actually need to read it. The underhanded C contest is a fantastic example of why you shouldn’t rely on the former, and the fact that you think you can “skip reading the files” is part of what’s wrong with the former.
If you are trying to establish trust, you need to find another way.
This is a more interesting conversation to have, but the tools are very bad.
Can you do the same with a curl|sh thing? No.
Wrong. curl | tee a.sh
And with a debian package, I can do that without having to read a random shell script to even have access to the files.
How about this: I’ll demonstrate I know what you’re saying by restating it, then you try to explain what you think I’m saying.
You’re saying that unpacking a binary archive puts assets in a more convenient format for review than (mentally) unpacking them from a shell script.
You’re admitting that if you skip the review step in either case, then there is no security difference between the two formats.
You believe that people are more likely to review a debian package than a shell script, and that this contributes to security.
Installing random stuff is bad.
Do you think that I’m arguing that installing random stuff is good? Or are you just trying to repeat enough obviously correct things that everyone will assume everything you’re saying is correct?
Not only is debian/rules not run during package installation (as mentioned by @algernon, it’s used during package build), debian/rules isn’t even a shell script. It’s a makefile.
Those two links are examples of how to do it, not examples of someone doing it.
A shell script via curl | sh (or curl | bash if you’re particularly terrible and don’t write portable shell scripts) also can’t realistically be signed, to prevent tampering/replacement.
Apparently creating a 1 line .list file and importing a GPG key is too much for people, so downloading the script, a signature and a GPG key is basically never going to happen.
A shell script via curl | sh (or curl | bash if you’re particularly terrible and don’t write portable shell scripts) also can’t realistically be signed, to prevent tampering/replacement.
If you use https: it is signed to prevent tampering/replacement.
Apparently creating a 1 line .list file and importing a GPG key is too much for people, so downloading the script, a signature and a GPG key is basically never going to happen.
The CA can revoke a SSL key. They can’t revoke a GPG key.
If you use https: it is signed to prevent tampering/replacement
How does https tell you that the file you downloaded is the same file the person/company you trust put on the server? The web server just gives you whatever file is on disk, and TLS encrypts it in transport.
I’m talking about gpg signing so you know the file in question is the same file the author you trust placed there, and it hasn’t been modified by someone else.
The CA can revoke a SSL key
Which is fucking irrelevant, as we’re talking about signing the file, not transport layer encryption.
I’m talking about gpg signing so you know the file in question is the same file the author you trust placed there, and it hasn’t been modified by someone else.
Yes, by neatly sidestepping the whole point of establishing that the author is deserving of that trust in the first place.
A GPG key downloaded from the website is no different, and in many ways may be less secure, since you seem to think a GPG key downloaded from the website is different.
The CA can revoke a SSL key
Which is fucking irrelevant, as we’re talking about signing the file, not transport layer encryption.
It’s something that SSL can do better than GPG. Given that GPG is in the proposed use less secure than SSL, I think that’s pretty “fucking” relevant.
Who said the gpg key had to be downloaded from the same server? Gpg key servers are a thing.
Comparing ssl (by which I assume you mean tls) and gpg is stupid. You can access a gpg signed apt repo over tls, they’re not mutually exclusive and they’re not even used for the same task here.
Who said the gpg key had to be downloaded from the same server? Gpg key servers are a thing.
There’s no difference between a key I’ve uploaded to one keyserver and a key I’ve uploaded to another keyserver.
You’re delusional if you think otherwise.
Comparing ssl (by which I assume you mean tls) and gpg is stupid.
Comparing the download of a key from an unencrypted keyserver with the DH key exchange is stupid. You have no idea what you’re talking about.
You can access a gpg signed apt repo over tls, they’re not mutually exclusive and they’re not even used for the same task here.
Nobody gives a fuck if you can get debian packages using carrier pigeons.
The point is that a GPG signed package doesn’t offer any security over HTTPS if nobody is bothering to check the GPG keys, because at least someone can check the keys used for HTTPS, and at least Google is doing that.
TLS/HTTPS can only ever at most protect you from MITM network attacks (and that assumes someone like WoSign hasn’t issued a cert for your domain to someone else, which.. you know, they did. multiple times.)
.Deb packages can be served over TLS, if you wish, to gain extra network level encryption, but they’re also GPG signed by default, so you can verify who authored them, regardless of where they have been served. Whether you choose to verify the GPG key is up to you.
You can’t realistically do that with a curl|sh script, just like you don’t get realistic safe upgrades, you don’t get realistic clean uninstall, etc etc.
What is just absolutely confusing to me is why are people defending this curl | sh nightmare
Because we want an actual secure system and not security theatre.
Telling people to install packages is just as risky as telling people to run scripts, and in some ways worse, since artificial conflicts can cause problems.
why do people want this to become a daily part of dev?
Ah, well this: I don’t.
I would’ve been happier if FHS had never happened, but it did, and we’re stuck with it. It’s a massive pile of crap that has made sysadmin work a special kind of misery until things like docker and (recent) practices of repeatable builds have started mitigating.
Yes: The debian [main] repository is more secure than a shell script for all of those reasons that I agree with (except perhaps the audit-ability step: Debian packages can contain executable code which is not – by accident in practice or malice in theory – completely invertible)
However when a distributor is starting out, competing with Debian (for whatever reason: time, etc), all they have to go on is developing that trust. These programs aren’t available in Debian yet, and might not be for some time. In this way, building and distributing a third-party .deb file is not better than building and distributing a shell script because they don’t get to take advantage of any of the benefits you mentioned, and they lose out on a very important disadvantage.
I’m really sorry to read the insults against you personally earlier on in this discussion, it is a damn shame that people would act that way in a technical discussion and I think you are admirable for replying to it so coolly.
They know how to basically write a shell script and put it in a http accessible directory, but find OS/Distro packaging (deb, rpm, macos pkg, etc) too hard/complicated?
I would assume the biggest supporters are probably involved in projects/companies that rely on curl|sh processes
Oh yeah, for those cases, I think it’s a symptom of the worst definition of “devops”: developers who can’t manage to add an apt repo source, are managing servers, and need cutesy bash one-liners to be anywhere close to productive.
I would have preferred to see this as a two-factor auth system versus a secret key store (e.g. “#{user} is trying to authenticate onto #{server}, confirm?”). Let me keep my secret keys where they are please.
Nothing wrong with the respective app stores. My fear comes from having private keys on a mobile device. Say someone gets a hold of Google’s kill switch, suddenly you have no more access to the things those private keys granted access. How many SMS exploits have been found in the last few years? :D
There are two issues, the phone can be bricked or at least made to require a factory reset remotely. I’m sure this is true of most phone operating systems.
Depending on the OS/uninstallation method if this app is removed, does it remove your local storage containing keys too?
A third possible issue, is your phone set up to back itself up to a cloud somewhere? Is that secure? (Spoiler alert: no)
Minor general usage issue, does the phone have to be on the same network (ie. Wifi) or does it go over the internet?
Why should I need my SSH key on my smartphone?
I’ve never seen or heard of anyone doing serious work with his phone/tablet, so what is a possible use case?
The question is no trolling, I am very curious about a use case for this, maybe I’ve missed some apps for being productive on Android.
I use it for authpf on OpenBSD to open the firewall for my current mobile IP to access my email server. That way I don’t need my mail server open to the general internet at all times. Usually I wait until I get home, but when traveling, it’s nice to have access to that account.
The ssh key is only used by my phone, only allowed for authpf and is password encrypted. I’ll eventually move to a VPN instead, but I’ve found VPNs to be quite a hassle on Android.
Also, it has bailed me out when accidentally blocking my home IP from a server at the firewall and I needed to get back in to remove that IP from the table.
I’ve used it a couple times on my iPhone (ssh on the phone that is, though the ssh app has a phone only key so its easy to revoke).
Its nice for following logs at the bar to find out when you can head back, other than that, using emacs or vi or trying to do almost anything is.. an exercise in frustration.
I haven’t taken a deep look at this, but doesn’t OpenSSH need frequent access to the secret key material? So what, it caches the authorization? And even if I’m mistaken, and openssh doesn’t need it more than once, it still needs to run the crypto to establish the session – so it’s sending the entire handshake, etc, over (wifi? bluetooth?) to the phone, and waiting for a response. Seems like an awfully long time, on top of the lag time anyways for a human to react to the notification. (And the notification, I expect, to appear after being pushed using FCN/APNS.)
I can’t find a good source right now, but my running assumption has been that the key material is only used to establish a session key, after which point it’s not needed, much like TLS. (Asymmetric crypto being relatively expensive vs. symmetric.) Hence SSH cipher suites including AES, etc.
[Comment removed by author]
Storing my key on the phone… Isn’t that exactly what we don’t want?
I wouldn’t trust my phone to store secrets. LG patch it only about twice a year. Even Google only patch their phones once a month. And we have not even started talking about intentional backdoors… So for the same reason I don’t (any more) store GPG keys on my phone, I will not store SSH keys on my phone.
I was wondering, how does the SSH client talk to the phone?
Your phone (at least for iOS) actually has pretty good secret storage. There was a great talk at BlackHat a few years ago about what Apple does: https://www.youtube.com/watch?v=BLGFriOKz6U
Yes, also some Android devices have it too (TEE/SE). The thing is that, if the device has none of these, any app with enough privileges could read your keys… just like on your computer.
I wouldn’t claim my computer to be saver (okay, okay, I actually would) but this “second factor, put all the trust into a corporate controlled, highly connected, often stolen mobile device” doesn’t make anything better.
Long story short : Use a Smartcard!
Smartcard++ It offers the convenience of having the keys on the device, while not having the keys on the device (at least on android - I haven’t found a way to do smartcards on iOS)!
Could you provide a link?
OpenKeychain is what I am using along with k-9 mail and Password Store, the auth api is still wip. I should have specified that I am not doing ssh stuff yet, sorry if I got your hopes up! :D
Ah this is the same setup as mine, but I’m using a yubikey neo (with nfc) to read the keys
Isn’t this basically what you’re supposed to be able to do with a YubiKey (i.e. a dedicated “physical key” that isn’t constantly accessible from the internet)? The idea of carrying around my ssh keys on my phone which can easily be stolen or hacked makes me nervous.
Cant your yubikey be stolen just as easily?
I’ve had my phone stolen out of my hand in the street. That’s a lot less likely with something you only use when logging in.
You can configure your YubiKey so that it needs a passphrase and will reset itself after a certain number of failed tries. It’s not a bad way to store a private key.
I’m not arguing that my phone is more secure, but my phone can be reset on failed attempts to login, too.
But, yes, Yubikeys are great.
Can’t hide a smartphone in your shoe.
You sure? https://www.doubleagentshoes.com/shop/en/
Soo…
That means that right now, I can do nothing with the code. I likely shouldn’t even look at it. Secondly, the bold part (emphasis mine): no, just no. Anything with a custom license is going to end up as a disaster.
Looking at the FAQ:
And this is software I should trust? Yeah, no.
[Comment removed by author]
curl | sh over HTTPS being insecure is FUD. It is just as secure as .deb/tarball over HTTPS, which for some reason I never hear people complaining about.
As a release engineer, the thing that bugs me the most about ‘curl | bash’ and that I never see mentioned, is that this format of installer almost never has a version number on it. I could run their script to install the thing on my system and make sure everything works. The next day, I can use the same command to install on another system and I don’t know that I got the same script and that the same things will get installed.
Package Managers enforce versioning and checksumming so you know you got the same, expected software.
‘curl | bash’ tells me, “We’re too lazy to package a release. You handle versioning, checksumming, and verification yourself”. And people accept that because they’re too lazy to do those things, too.
This is a good point, curl|sh also doesn’t really have a single answer for “how do i upgrade”.
For some it’s ‘run the same curl|sh again’, for others this may wipe your current installation and data.
Honestly the most ridiculous ones (in terms of rube goldbergness) are the 200 line shell scripts that add a custom apt repo, and then install a heap of dependencies, before installing the main package.
Because declaring dependencies in the package is apparently as hard as giving people instructions about creating a .list file (or providing a release .deb)
As someone who has had to do the reverse-engineering for those types of scripts, I couldn’t agree more.
They’re all symptoms of the same problem, right up there with the use of npm and docker. Not sure what to call it… Misguided inaptitude?
“Cargo culting cool-kid bullshit” comes to mind, but I may just be angry.
There is a huge difference between a deb and
curl | shthough, in that I can extract the contents of the deb without running any of the scripts (dpkg-deb -x). It has a well defined format, too. I can easily uninstall it, and so on and so forth.Figuring out what a random shell script does is not quite the same.
Also read this - https won’t protect you from malicious code. Precise installation steps, or packages one can inspect more easily, are far superior to
curl|sh. If someone does not take the effort to explain how to install their software, why should I trust them that they’ll do anything else right?While someone could do malicious/stupid things in the maintainer scripts of a .deb, I’ve literally never seen that happen.
With a .deb, you can see what files will be installed where, you can extract the contents, and (barring the aforementioned stupidity in maintainer scripts) you can REMOVE the software, cleanly.
With a .sh script, well fuck you, read the whole god damn thing, and then go fetch whatever shit it downloads and examine that too.
deb files have an embedded shell script that performs installation tasks, called
debian/rulesthat, “fuck you”, you need to read the whole thing.There’s also all those downgrade attacks that used to be popular.
No, they do not.
debian/rulesis used for building a debian package, not when installing. They can have various scripts that run during installation, but you can extract the contents without running any of those (dpkg-deb -x). So no, you do not have to read the whole thing, if you want to have a look at what it installs and where. You can even list the files, without extracting them.The same can’t be said about a
curl|shthing.As for the two links: Both do their thing in the postinst. One can extract the files only, nullifying their malicious behaviour. You can look at the files without running code. With
curl|sh, you can’t. You will have to download and read the shell script to figure out where to get the files from.Fine. Everything I said still applies to postinst though.
Sure you can.
curl > a.shread it, then run it. Same as with postinst.Point is, I can look at the files without running the postinst. I have the files without any code to run, or look at. Can’t say the same about the shell script. I still have to go through it and download the files separately.
Not nearly the same, not by a long shot.
Point is, you can look at a shell script without running it.
Or maybe you can’t, and you should learn how to improve that?
Your choice to insult someone who disagrees with you reflects on you poorly (not to mention it is extremely unlikely to be true).
My bash is excellent, so I decided to audit a few
curl | installscripts awhile back.The first one took over an hour to review - it pulled in quite a few different other scripts from several domains, none of which did anything obviously untowards (although given how many ways there are to hide a subtle backdoor in a shell script I wouldn’t be that confident).
Anything that shrinks the amount of bash code I have to read to audit a package is a win, and in practice deb postinstall scripts are much shorter.
I think it’s interesting that you find it insulting if someone observes you cannot do something.
You can’t say “well, I looked at less code so it must be more trustworthy” – the code actually has to be shorter. You still have to look at the binaries in the package, or what’s the point?
My mind is boggled that someone thinks there is something about an archive file containing another archive file, with executable scripts at both layers, more trustworthy than an executable script, when they don’t bother reading either.
You observed nothing of the sort; you insinuated, on no basis other than a disagreement, a lack of competence with one of the primary languages used by package maintainers in someone who is one.
Nonsense. He said he can’t look at a script, and doesn’t know how to save files with curl.
You are, again, missing the point. With a package, I have access to all the files, and the scripts. I can look at the files without reading the scripts.
With a
curl|sh, I do not have the files, and I have to read the script to get access to the files.Being able to is one thing, having to is another, and willing to is a third.
The type slower.
I actually don’t get your point.
I think people trust
.debfiles more than they trust.shfiles, and my point is that there’s no reason to.If you think there is, then you’re going to have to explain why, and you’re going to have to do better than
dpkg-deb -xbecause that’s a crock of dogshit that tries to make up some cocked up definition for “secure” that has nothing to do with reality: It doesn’t keep more people safe from harm even hypothetically.Don’t insult my intelligence: I haven’t done that to you.
You don’t have the files when you do
curl -O && dpkg -ieither, which is why you don’t do that. Why would you do that, even if the website says to?Because we’re talking about trust. I trust esl-erlang even though they tell me (basically) to do that, because at the end of the day, I’m not going to audit the binaries in the archive. I’m going to trust their TLS certificate, just like I’ve trusted the one at debian.org.
You don’t want to trust it, yes Virginia, you absolutely need to read the whole fucking thing. Not just the postinst, but also the things in the tarball that you are ignoring.
There actually is. Because with a deb file, it is a lot easier to ignore the script parts, and have a look at the files. Obviously, if you blindly install one, that is in no way more secure than
curl|sh- but that’s not what I’m talking about. I’m talking about a way to inspect what it wants to install. With a package (deb, rpm or even a tarball), I can do that. I can download it, and have the files.With
curl|sh, I first have to read the whole script, and then inspect the files.I hope we can agree that having the files at hand is a better starting point than first having to figure out where and how to get them from. With a shell script, I’d have to do additional reading, which I don’t need to do when facing a package or a tarball.
Well, for one,
dpkg-deb -xis not going to run random commands on my system (because it just extracts a tarball, and does not run maintainer scripts). Nor will it put files in random places (because it puts them in a directory I point it at). I’ll have more control over what it does. That is safer than running a random shell script.And yes, I could read a shell script. But I have better things to waste my time on than read a random script, because people thought that making a tarball is too hard.
I trust deb packages not because they are inherently more secure - they are not. I trust them more, because I have tools to help me inspect their contents. Or, to put it another way: I distrust
curl|shbecause it has so many disadvantages, and so little gains over even a simple tarball, that I fail to see its appeal. And even worse, the suggestion to pipe a random script into your shell, coming from the developers of a tool aimed at improving security is just… insane. THAT is my problem. If they’d suggest blindly installing a debian package, I’d call that bad practice too. Now, if they provide a repo, or a tarball, that’s a whole different story.Of course I won’t run
dpkg -i. I’ll rundpkg-deb -x foo.deb /tmp/blah, and voila, I have the files without any of the random scripts run. Can you do the same with acurl|shthing? No. You’d have to read the whole thing, download the files, and then inspect them. With a package, or even a tarball, this is a whole lot easier. There can still be maintainer scripts, but those are typically small. Not to mention, that I won’t have to read any scripts just to be able to look at the binaries.More secure, safer? Probably not. Easier? Less error prone? Yes. And that is my point. A directly downloadable package is easier to verify.
If they’d suggest
curl -O && dpkg -i, I’d call that bad practice too, by the way. Installing random stuff is bad. Having an easy way to inspect random stuff is, therefore, better than also having to read and understand random shell scripts on top of everything else.No, I’m not ignoring. I’m extracting them with
dpkg-deb -xprecisely because I want to look at them. And with a debian package, I can do that without having to read a random shell script to even have access to the files.However it’s what I’m talking about.
So thank you for conceding to my point and agreeing with me.
No, I can’t agree with that.
The biggest problem with Debian and Linux is the fact that the tiniest hole can often be exploited into something bigger.
If you’re relying on your ability to read, then you actually need to be able to read, and you actually need to read it. The underhanded C contest is a fantastic example of why you shouldn’t rely on the former, and the fact that you think you can “skip reading the files” is part of what’s wrong with the former.
If you are trying to establish trust, you need to find another way.
This is a more interesting conversation to have, but the tools are very bad.
Wrong.
curl | tee a.shHow about this: I’ll demonstrate I know what you’re saying by restating it, then you try to explain what you think I’m saying.
You’re saying that unpacking a binary archive puts assets in a more convenient format for review than (mentally) unpacking them from a shell script.
You’re admitting that if you skip the review step in either case, then there is no security difference between the two formats.
You believe that people are more likely to review a debian package than a shell script, and that this contributes to security.
Do you think that I’m arguing that installing random stuff is good? Or are you just trying to repeat enough obviously correct things that everyone will assume everything you’re saying is correct?
What’s your point here?
Not only is
debian/rulesnot run during package installation (as mentioned by @algernon, it’s used during package build),debian/rulesisn’t even a shell script. It’s a makefile.Those two links are examples of how to do it, not examples of someone doing it.
A shell script via curl | sh (or curl | bash if you’re particularly terrible and don’t write portable shell scripts) also can’t realistically be signed, to prevent tampering/replacement.
Apparently creating a 1 line .list file and importing a GPG key is too much for people, so downloading the script, a signature and a GPG key is basically never going to happen.
If you use https: it is signed to prevent tampering/replacement.
The CA can revoke a SSL key. They can’t revoke a GPG key.
How does https tell you that the file you downloaded is the same file the person/company you trust put on the server? The web server just gives you whatever file is on disk, and TLS encrypts it in transport.
I’m talking about gpg signing so you know the file in question is the same file the author you trust placed there, and it hasn’t been modified by someone else.
Which is fucking irrelevant, as we’re talking about signing the file, not transport layer encryption.
Yes, by neatly sidestepping the whole point of establishing that the author is deserving of that trust in the first place.
A GPG key downloaded from the website is no different, and in many ways may be less secure, since you seem to think a GPG key downloaded from the website is different.
It’s something that SSL can do better than GPG. Given that GPG is in the proposed use less secure than SSL, I think that’s pretty “fucking” relevant.
Who said the gpg key had to be downloaded from the same server? Gpg key servers are a thing.
Comparing ssl (by which I assume you mean tls) and gpg is stupid. You can access a gpg signed apt repo over tls, they’re not mutually exclusive and they’re not even used for the same task here.
There’s no difference between a key I’ve uploaded to one keyserver and a key I’ve uploaded to another keyserver.
You’re delusional if you think otherwise.
Comparing the download of a key from an unencrypted keyserver with the DH key exchange is stupid. You have no idea what you’re talking about.
Nobody gives a fuck if you can get debian packages using carrier pigeons.
The point is that a GPG signed package doesn’t offer any security over HTTPS if nobody is bothering to check the GPG keys, because at least someone can check the keys used for HTTPS, and at least Google is doing that.
You’ve missed the point, multiple times now.
TLS/HTTPS can only ever at most protect you from MITM network attacks (and that assumes someone like WoSign hasn’t issued a cert for your domain to someone else, which.. you know, they did. multiple times.)
.Deb packages can be served over TLS, if you wish, to gain extra network level encryption, but they’re also GPG signed by default, so you can verify who authored them, regardless of where they have been served. Whether you choose to verify the GPG key is up to you.
You can’t realistically do that with a curl|sh script, just like you don’t get realistic safe upgrades, you don’t get realistic clean uninstall, etc etc.
[Comment removed by author]
Because we want an actual secure system and not security theatre.
Telling people to install packages is just as risky as telling people to run scripts, and in some ways worse, since artificial conflicts can cause problems.
Ah, well this: I don’t.
I would’ve been happier if FHS had never happened, but it did, and we’re stuck with it. It’s a massive pile of crap that has made sysadmin work a special kind of misery until things like docker and (recent) practices of repeatable builds have started mitigating.
[Comment removed by author]
Yes: The debian [main] repository is more secure than a shell script for all of those reasons that I agree with (except perhaps the audit-ability step: Debian packages can contain executable code which is not – by accident in practice or malice in theory – completely invertible)
However when a distributor is starting out, competing with Debian (for whatever reason: time, etc), all they have to go on is developing that trust. These programs aren’t available in Debian yet, and might not be for some time. In this way, building and distributing a third-party
.debfile is not better than building and distributing a shell script because they don’t get to take advantage of any of the benefits you mentioned, and they lose out on a very important disadvantage.I appreciate that.
Thank you.
That’s fair (re security), though I’d hope the result is at least easier to uninstall cleanly.
They know how to basically write a shell script and put it in a http accessible directory, but find OS/Distro packaging (deb, rpm, macos pkg, etc) too hard/complicated?
I would assume the biggest supporters are probably involved in projects/companies that rely on curl|sh processes
That makes so little sense for the scripts that add a repo.
I think someone had the idea that adding a repo is hard, let’s make a one-line install to get people hooked, and matters proceeded from there.
Oh yeah, for those cases, I think it’s a symptom of the worst definition of “devops”: developers who can’t manage to add an apt repo source, are managing servers, and need cutesy bash one-liners to be anywhere close to productive.
I would have preferred to see this as a two-factor auth system versus a secret key store (e.g. “#{user} is trying to authenticate onto #{server}, confirm?”). Let me keep my secret keys where they are please.
/me clicks link - sees links to Play store and App store…. NOOOOPE!
[Comment removed by author]
Nothing wrong with the respective app stores. My fear comes from having private keys on a mobile device. Say someone gets a hold of Google’s kill switch, suddenly you have no more access to the things those private keys granted access. How many SMS exploits have been found in the last few years? :D
[Comment removed by author]
There are two issues, the phone can be bricked or at least made to require a factory reset remotely. I’m sure this is true of most phone operating systems. Depending on the OS/uninstallation method if this app is removed, does it remove your local storage containing keys too? A third possible issue, is your phone set up to back itself up to a cloud somewhere? Is that secure? (Spoiler alert: no) Minor general usage issue, does the phone have to be on the same network (ie. Wifi) or does it go over the internet?
Why should I need my SSH key on my smartphone? I’ve never seen or heard of anyone doing serious work with his phone/tablet, so what is a possible use case?
The question is no trolling, I am very curious about a use case for this, maybe I’ve missed some apps for being productive on Android.
I use it for authpf on OpenBSD to open the firewall for my current mobile IP to access my email server. That way I don’t need my mail server open to the general internet at all times. Usually I wait until I get home, but when traveling, it’s nice to have access to that account.
The ssh key is only used by my phone, only allowed for authpf and is password encrypted. I’ll eventually move to a VPN instead, but I’ve found VPNs to be quite a hassle on Android.
Also, it has bailed me out when accidentally blocking my home IP from a server at the firewall and I needed to get back in to remove that IP from the table.
OpenVPN on Android is actually quite easy to use with openvpn for android, maybe you should give it a try.
I’ve used it a couple times on my iPhone (ssh on the phone that is, though the ssh app has a phone only key so its easy to revoke).
Its nice for following logs at the bar to find out when you can head back, other than that, using emacs or vi or trying to do almost anything is.. an exercise in frustration.
I use SSH for file transfer from my cell to my server at home.
Can’t help wondering if it might actually be easier to just type in the passphrase. Assuming you can remember it, obviously ;-)
I haven’t taken a deep look at this, but doesn’t OpenSSH need frequent access to the secret key material? So what, it caches the authorization? And even if I’m mistaken, and openssh doesn’t need it more than once, it still needs to run the crypto to establish the session – so it’s sending the entire handshake, etc, over (wifi? bluetooth?) to the phone, and waiting for a response. Seems like an awfully long time, on top of the lag time anyways for a human to react to the notification. (And the notification, I expect, to appear after being pushed using FCN/APNS.)
I can’t find a good source right now, but my running assumption has been that the key material is only used to establish a session key, after which point it’s not needed, much like TLS. (Asymmetric crypto being relatively expensive vs. symmetric.) Hence SSH cipher suites including AES, etc.