You're damn if you do and you're damn if you don't...
Funny tho I never saw configure asking for root password.
sudo make install
naa, don't do that. Pollutes your systemroot. Configure with --prefix="somewhere in your homefolder" and make install without sudo.
It's the way to go. I cannot expect them to RTFM tho.... 🙄
On my machine I typically do
sudo mkdir /usr/local/appnamesudo chown sweh.sweh /usr/local/appname
And then configure for that target.
Great technique! I'll try it.Also http://user.group? Or : ?
Linux coreutils "chown" accepts both syntaxes. I think one came from BSD and one from SysV, but I might be misremembering. POSIX specifies : so, really, that should be used for compatibility (just in case a username has a . in it).
On an unrelated note, you ever used (managed) systemd sandbox?
I need a sandbox mechanism for those Electron app cancer.
No, I've never used it.
Depends who you're installing it for. And what decade it is.
That's not configure...
Running something created by an obfuscated shell script is broadly equivalent to running an obfuscated shell script.
What's your point? Because following your logic you shouldnt even trust the source code, because so much lines = obfuscated!And FYI configure is also generated. If you're not satisfied/trusting the one provided you can still write your http://configure.am 😉
You’ll like this book then: https://www.amazon.co.uk/Die-GNU-Autotools-Leitfaden-Softwaredistribution/dp/3936546487
Yeah, or just issue ye old configure; make; make install
TBH, it has been ages since I've done that... is trusting the distros and their repos better or worse?
Well confirm the hash first wildman!
And forget to compare the md5 on that source that the https gave you for free :)
... transport security != provenance of content delivered over the transport...
Totally true. ./configure doesn’t give you that either :)
I get it, but there are many work environments out there where human-curated and validated provenance for checking signatures and shasums on source tarballs is a thing. There’s even some gradle integration, if you’re a java shop, for example.
I know we implicitly trust the upstream authors (and the control of their signing keys, etc) but you have to anchor trust somewhere. And it doesn’t have to be a https web server that can detect curl | sh and start a reverse shell instead of the tarball you’d be served w/just curl
I was giving a tongue-in-cheek answer to a funny tweet. You are absolutely right. However, I don't think *most* current systems give you "much" more protection than curl |. I have really high hopes for systems like firefox update and cothority.
There’s a lot that can and is being done in secure software development; I suspect we’ll see “supply chain” attacks pick up in 2018. On the app updating side, TUF has been around for a while now and I’ve been impressed with @CiPHPerCoder’s Chronicle https://paragonie.com/blog/2017/07/chronicle-will-make-you-question-need-for-blockchain-technology
There’s a loud portion of developer culture with unsafe practices in many many ways... blind curl | sh, being unable to say where a software component came from (or what the licenses are) are some of them. But that’s not everyone.. others have been, continue to do better
For the users, distros like Debian have per-contributor signing keys for pushing software into controlled build environments and you as the end user can be reasonably sure that if the package manager says it’s trusted, it came through their infra & process
Debian in particular has the reproducible builds project and enough process in place that they are able to have consensus builds soon. Most packages build exactly the same, bit-for-bit, on any machine
It taskes a lot of work to get even this far and trust is still involved, but I go a little crazy when people assume https:// is the end of the road for what software & security engineering discipline has to offer :P
For sure and trusting your distro packages is waaaaay safer. I’d argue that installing a random repo and installing a package from there is not actually much safer.
But anyway I think we agree on 99% and I think you put out a bunch of great info here.
Thanks for the link! Seems similar to trillian. I’m all about those projects. I worry about incentives when it comes to the “non-Blockchain.” I wonder if there’s an intermediate idea where you just pay someone a dime to co-sign your ledger.
Particularly just blindly adding third-party dependencies..https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5
No cryptography protocol can fix stupidity, but it can at least hold the dependency developers accountable.
Also Test and Eval labs. We have to verify what we are putting on there is what we put on there.
Linux Mint: A bit who, the Linux Mint repo was hacked and hosed a malicious ISO, but never changed the SHA256 sun on the website
FYI: An attacker will nave no problem finding a hash collision I’m MD5 or SHA1 they are both completely broken.
Which is why I chose md5 for my joke answer :). There are a lot of good points below though and state of the art security does provide reasonable trust... just that state of the art hasn’t been evenly distributed yet.
Can’t keep myself from pointing out that SHA2-256bit is not the _Sate Of the Art_ hashing algo
It is the minimum acceptable hashing algo
You need to look into SHA3
Have you got a handy curl slip to do that? :)(btw, sha256 for the win)For Apache software releases we always recommend GPG verification against KEYS file (downloaded over https!)https://www.apache.org/info/verification.html
You can install an IDE plugin from an SV company that’ll upload all of your ~ to their servers and then give you an embedded terminal with helpful keylogger to `sudo make install` with ANSI colors.
I want to make a joke that downloading it with wget instead is more secure, but someone will probably think I’m serious.
wget uses https, bash doesn't.QED.
300Kb shell script will get you a production kubernetes setup up and running
I wonder if there is a tool for managing programs as packages...
It’s called SETUP.EXE
that's also the solution to copy and pasting code from your webbrowser to your shell.
but.. all my friends recommended it to me! .. with the same text... over twitter... oh...
You had me at "obfuscated shell script" ;)
*unless it was obfuscated by DaaS. Then it's definitely safe 😉
What is this DaaS you speak of?
Really, you foolishly missed out on asking "was ist DaaS"?
naaa, for good measure, check the md5 of the code against the md5 - which you get from the same place as the code…
md5sum “rm -rf *”
Is anyone working on a fix to this? Can containers be made convenient enough to alleviate this problem?
You can serve different results to wget piped into a shell than regular wget or a webpage peeking at the file, so it’s still a somewhat worse idea
The bar for making a source tarball with a configure script do evil (or even anything) is far higher than curling one out to bash. Either way you are still shitting you own bed if you don't use a package manager.
Was this ever in doubt?
not 'sudo ./configure && make install' ?
What's sudo? I always log in as root.
Randomly install WordPress plugins and Google Chrome addins. Install the most obscure Android apps from developers you've never heard of. Run any old code from random sources. It's how we roll in 2018.
Buried deep within the resultant Makefiles will be something like:
curl -o /tmp/getdeps https://someplace.example/mydeps curl -o /tmp/getdeps.sums https://someplace.example/mydeps.sums md5sum -c /tmp/getdeps.sums chmod 755 /tmp/getdeps sh /tmp/getdeps
Both of these sound like absolutely horrible ideas.
I'll just add this unknown ppa to apt
Welp run Arch Linux. Use the package from AUR, and have a little faith the maintainers read the ./configure scripts. Mostly not. Or if there is no PKGBUILD, be kind and carefully audit before you post and always use VALIDGPGKEYS= and sha256 sums
Saves a lot of time, as you only have to check a few pieces of software, and other people can check other pieces of software, and it becomes a group effort. Then again, the vast bulk of PKGBUILDs on AUR are questionable quality
But OP makes a valid point. Same difference. even with make, itself scriptable. You can hide malware in anything.
Still doesn't negate the concept of reading 10 lines of bash you wget before executing it. That bash will also probably call ./configure as well.
Surely you mean "sudo ./configure" 😃
http://Pivpn.io - the first instruction ::: INSTALLATION ::: curl -L https://install.pivpn.io | bash
The reason people are told to download & run scripts instead of `curl | bash` is because the CGI application knows that you are piping into bash, so the CGI app can send you different data if it knows your piping into bash instead of writing to a file.
How does the CGI application know that you're piping into bash, or piping into any process at all?
Node.js script that can detect when "curl ... | bash" is being used and serve a different file than normal. This is an implementation of this article https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/“
Well this is going to keep me up at night.
How does it know it is bash, as opposed to zsh, ash, SVR4 ksh, dtksh, or "dd of=/etc/shadow" or even ncftp (in upload-elsewhere mode)? It doesn't.
“Node.js script that can detect when "curl ... | bash" is being used and serve a different file than normal.”
It doesn't matter. The point is that nobody audits the downloaded source either way.
They do if the code the complied is doing something which looks malicious
Someone who dose not read the source code for a program which is behaving maliciously is an idiot, and irrelevant to the conversation.
If you audit only after you notice malicious activity, that's generally too late — you're pwnd already. Calling victims idiots is an immature and ineffective approach to security.
I agree that it suck when you have to recover from an attack.
However, it is far easier to figure out what has gone wrong if you can read the source code you complied the binary from, rather than using IDA Pro.
./configure scripts are plain text. Still, I think it doesn't matter, as you may be one of very few people on the entire planet inclined to audit them manually.
I think the main risk is not malice but that a line like “rm -rf /tmp/tmpfile” gets cut off after the first slash due to a network interruption.
Don't forget to specify http on that download too
Nixpkgs runs ./configure in a chroot jail with no network connection.
And then it probably runs "make", hopefully in that same jail, and you get a binary file that you still need to trust. Seriously, curl | bash is no worse than any other method that doesn't involve a trusted third person checking the code.
I think you missed a sudo in there. Also an untrusted source is an untrusted source no matter the execution pattern. Either learn how to read obfuscated shell scripts or find a different means to trust the solution for the problem you are trying to solve.
This sounds related to an issue I read somewhere where someone complained about a script that, run after curl d/l, installed a compilation tool for a language from a reputable source.
No, that could do something dangerous. Instead download the precompiled binary and then blindly execute the 100MB .exe
it's also easy to modify a web server to differentiate on User-Agent header; return a "kind" version to browsers and an evil one to curl.
But you don't run ./configure as root, as opposed to curl | sudo bash
I just download them to see if any inspirational trixy-hobbitz bashisms used...
Or run sudo npm install -g.