Re: [Nix-dev] Malicious installation methods

2016-06-22 Thread Teo Klestrup
It's not strictly required, but it would mean losing out on all the binary packages provided by the CI. On 17 Jun 2016 20:54, "Yui Hirasawa" wrote: > >>> True, of course. But, there is a class of software projects which will > >>> likely never be "packaged" by package managers -

Re: [Nix-dev] Malicious installation methods

2016-06-19 Thread Yui Hirasawa
>> If you sign the script and it contains say sha512sums for the things it >> pulls you don't have to sign them separately. It's similiar to how many >> distributions only distribute one file with all the sums that is signed. > > I don't think there's no easy way for the user to verify such sums,

Re: [Nix-dev] Malicious installation methods

2016-06-19 Thread Profpatsch
On 16-06-18 11:46pm, Bardur Arantsson wrote: > On 06/18/2016 11:18 PM, Profpatsch wrote: > > > > The script approach is not very bad. Maybe sign it with gpg for people > > who want to verify it. > > > > Have you been following along on the thread at all? Signing the > installer script does very

Re: [Nix-dev] Malicious installation methods

2016-06-18 Thread Bardur Arantsson
On 06/18/2016 11:18 PM, Profpatsch wrote: > > The script approach is not very bad. Maybe sign it with gpg for people > who want to verify it. > Have you been following along on the thread at all? Signing the installer script does very little[1] unless the bits it fetches are themselves also

Re: [Nix-dev] Malicious installation methods

2016-06-18 Thread Profpatsch
On 16-06-18 05:27pm, Michiel Leenaars wrote: > Regarding the installer: it would be cool to have something like > http://appimage.org, http://orbital-apps.com, http://flatpak.org or > http://snapcraft.io instead of a shell script. That would have a SHA > that could be verified, etc. It would be

Re: [Nix-dev] Malicious installation methods

2016-06-18 Thread Michiel Leenaars
Hi all, >> Is the nix root dir configurable? Would it be that horrible >> to have /opt/nix or /var/lib/nix or something else be the nix >> root on Debian? > It's not strictly required, but it would mean losing out > on all the binary packages provided by the CI. although it would mean a Big

Re: [Nix-dev] Malicious installation methods

2016-06-18 Thread Moritz Ulrich
Yui Hirasawa writes: > Is the nix root dir configurable? Would it be that horrible to have > /opt/nix or /var/lib/nix or something else be the nix root on Debian? It is, but changing it means you can't use the binary cache anymore as all paths change.

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Vladimír Čunát
On 06/18/2016 12:00 AM, Yui Hirasawa wrote: >> > Because it invalidates all the store references. > Seems like nix needs some redesign then. It's also the upstream packages... most of them require absolute paths to locate their files, and I don't blame them as IMHO that approach saves some

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Maarten Hoogendoorn
First of all, you can install nix in another location, but then you won't be able to use the binary cache anymore. I thought a bit about how we could make this work: - store the nix store physically in /var/lib/nix/store on Debian - create a union fs in /var/lib/nix/nix-root of / and

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Yui Hirasawa
>>> True, of course. But, there is a class of software projects which will >>> likely never be "packaged" by package managers - namely, other package >>> managers. Nix falls into this class, along with, for example, NPM, >>> Brew, Oh-My-Zsh, and others. >> >> What reason

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Shell Turner
>>> Is the nix root dir configurable? Would it be that horrible to have >>> /opt/nix or /var/lib/nix or something else be the nix root on Debian? >> >> It's not strictly required, but it would mean losing out on all the binary >> packages provided by the CI. > > Aren't they built in a chroot like

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread joachifm
On Fri, Jun 17, 2016, at 11:36 PM, Yui Hirasawa wrote: > > True, of course. But, there is a class of software projects which will > > likely never be "packaged" by package managers - namely, other package > > managers. Nix falls into this class, along with, for example, NPM, > >

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Yui Hirasawa
> True, of course. But, there is a class of software projects which will > likely never be "packaged" by package managers - namely, other package > managers. Nix falls into this class, along with, for example, NPM, > Brew, Oh-My-Zsh, and others. What reason would there to

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Yui Hirasawa
>>> True, of course. But, there is a class of software projects which will >>> likely never be "packaged" by package managers - namely, other package >>> managers. Nix falls into this class, along with, for example, NPM, >>> Brew, Oh-My-Zsh, and others. >> >> What reason would there to not package

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Eelco Dolstra
Hi, On 06/17/2016 08:01 PM, Yui Hirasawa wrote: >> True, of course. But, there is a class of software projects which will >> likely never be "packaged" by package managers - namely, other package >> managers. Nix falls into this class, along with, for example, NPM, >> Brew, Oh-My-Zsh, and

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Yui Hirasawa
>>> I ask the members of the list to point to a software project that is >>> doing this >> >> Any software project that is telling the user to install the software >> using the package manager of their distribution. Pretty much all package >> managers verify signatures and they are really

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Robin Bate Boerop
On 17 June 2016 at 11:42, Yui Hirasawa wrote: >> I ask the members of the list to point to a software project that is >> doing this > > Any software project that is telling the user to install the software > using the package manager of their distribution. Pretty much all package >

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread zimbatm
On Fri, 17 Jun 2016 at 15:19 Yui Hirasawa wrote: > >>> Like already said before, detecting if a user run a curl-pipe-bash and > >>> injecting a malicious binary on the fly is rather trivial to do > compared > >>> to compromise the nixos website itself, and create a phising to fake

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Yui Hirasawa
> I ask the members of the list to point to a software project that is > doing this Any software project that is telling the user to install the software using the package manager of their distribution. Pretty much all package managers verify signatures and they are really convenient for the

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Robin Bate Boerop
On 17 June 2016 at 11:12, zimbatm wrote: > Pretty good SSL: https://www.ssllabs.com/ssltest/analyze.html?d=nixos.org > > I wonder if something like this would be better perceived: I ask the members of the list to point to a software project that is doing this (providing

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread zimbatm
Pretty good SSL: https://www.ssllabs.com/ssltest/analyze.html?d=nixos.org I wonder if something like this would be better perceived: sudo mkdir /nix curl https://nixos.org/$(arch)nix.tar.gz | sudo tar -C /nix xvfsudo /nix/post-install Or I wonder if there was a universal script that would wrap

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Yui Hirasawa
>> The installer, when run, will fetch more code for users to blindly >> execute (as most of that code will be provided in compiled form). How >> is blindly running an installer worse than running other code from >> the same provider? > > Simply put the shasum of your installer on the website and

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Yui Hirasawa
> Like already said before, detecting if a user run a curl-pipe-bash and > injecting a malicious binary on the fly is rather trivial to do compared > to compromise the nixos website itself, and create a phising to fake > both the tarball and the displayed hash. Hash would only ensure that there

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Adrien Devresse
> So you're trusting a hash from the same site that you are downloading > the script from? I can see a lot of value in a cryptographic signature > (like PGP) but I see almost no value in a hash. > Briefly, yes. This is already a security improvement. Like already said before, detecting if a user

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Yui Hirasawa
>> But without even considering that, "curl-pipe-bash" will cause your >> sysadmin to blow a fuse or heartbreak in most companies / environments. >> And for very good reasons. > > That is not very different from a "make install" of a downloaded tarball, > though. :) The fact that when you build

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Lluís Batlle i Rossell
On Fri, Jun 17, 2016 at 03:17:59PM +0200, Adrien Devresse wrote: > But without even considering that, "curl-pipe-bash" will cause your > sysadmin to blow a fuse or heartbreak in most companies / environments. > And for very good reasons. That is not very different from a "make install" of a

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Eelco Dolstra
Hi, On 06/17/2016 03:02 PM, Ertugrul Söylemez wrote: > For marketing reasons it may be beneficial to attach a security note to > that command, such that people understand why it's really not any less > secure than other methods. Alternatively get rid of the pattern and > distribute a bunch of

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Kevin Cox
On 17/06/16 09:17, Adrien Devresse wrote: >> The installer, when run, will fetch more code for users to blindly execute >> (as most of that code will be provided in compiled form). How is blindly >> running an installer worse than running other code from the same provider? > > Simply put the

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Adrien Devresse
> The installer, when run, will fetch more code for users to blindly execute > (as most of that code will be provided in compiled form). How is blindly > running an installer worse than running other code from the same provider? Simply put the shasum of your installer on the website and ask the

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Ertugrul Söylemez
>> I ask you to PLEASE remove this installation method from the >> recommendations on the page because it makes it look like you don't >> care about computer secuirty one bit. > > Now, that's an interesting point. Are there many people who never > installed nix because the installer is the

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Kevin Cox
On 17/06/16 07:59, Azul wrote: > simple as that, > just don't do it. > > https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ > While this is interesting research I find that it is often irrelevant because you are trusting the server anyways. So if you trust the server

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Tomasz Kontusz
Dnia 17 czerwca 2016 13:12:57 CEST, Yui Hirasawa napisał(a): >I recently noticed that you recommend very malicious installation >methods on your download page for nix[1] > >Retrieving code straight from the internet and blindly executing is >never a good thing and you don't give

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Azul
simple as that, just don't do it. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ On 17 Jun 2016 12:38, "Kevin Cox" wrote: > On 17/06/16 07:12, Yui Hirasawa wrote: > > > > Retrieving code straight from the internet and blindly executing is > >

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Kevin Cox
On 17/06/16 07:12, Yui Hirasawa wrote: > > Retrieving code straight from the internet and blindly executing is > never a good thing and you don't give any sort of recommendation for the > user to inspect the script before running it. This completely defeats > the point of having reproducible