date:20160617

>>> 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 other package managers?
>
> IIRC, Debian won't package Nix because it violates the FHS (by requiring
a /nix
> directory).

 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 Guix does? Why would anything break
>> just because you change where they are installed?
>
> Because it invalidates all the store references.

Seems like nix needs some redesign then.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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 Guix does? Why would anything break
> just because you change where they are installed?

All Nix packages refer to their dependencies by their full path. It's
embedded in binaries, config files, etc etc.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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,
> > Brew, Oh-My-Zsh, and others.
> 
>  What reason would there to not package other package managers?
> >>>
> >>> IIRC, Debian won't package Nix because it violates the FHS (by requiring
> >>a /nix
> >>> directory).
> >>
> >> 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 Guix does? Why would anything break
> just because you change where they are installed?

Because it invalidates all the store references.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Malicious installation methods

> 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 other package managers?
>>>
>>> IIRC, Debian won't package Nix because it violates the FHS (by requiring
>>a /nix
>>> directory).
>>
>> 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 Guix does? Why would anything break
just because you change where they are installed?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Malicious installation methods

>>> 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 other package managers?
>
> IIRC, Debian won't package Nix because it violates the FHS (by requiring a 
> /nix
> directory).

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?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Malicious installation methods

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 others.
> 
> What reason would there to not package other package managers?

IIRC, Debian won't package Nix because it violates the FHS (by requiring a /nix
directory).

> There is no reason to not package your package manager other than
> laziness and desire to not have adoption. Especially Nix and Guix are
> package managers that would make a lot of sense to package for other
> distributions to make the adoption easier.

We do have Fedora / Ubuntu / Debian packages, but they're no longer advertised
because they're not well tested.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Malicious installation methods

>>> 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 user,
>> even more convenient than the curl | sh method since the user doesn't
>> have to go to the project's website to find out what exactly they are
>> supposed to curl and what are they supposed to pipe it to and as which
>> user it should be done as.
>
> 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 other package managers?

Quick search on Parabola tells me that there are at least a few package
managers that are packaged for it. Also cpan is included in the perl
package.

npm, pip, dub, nuget, cargo, bower, nimble, shards

> I wonder whether there are other software projects *in this class*
> which are easy and secure to install?

The ones above.

There is no reason to not package your package manager other than
laziness and desire to not have adoption. Especially Nix and Guix are
package managers that would make a lot of sense to package for other
distributions to make the adoption easier.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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
> managers verify signatures and they are really convenient for the user,
> even more convenient than the curl | sh method since the user doesn't
> have to go to the project's website to find out what exactly they are
> supposed to curl and what are they supposed to pipe it to and as which
> user it should be done as.

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.

I wonder whether there are other software projects *in this class*
which are easy and secure to install?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] ed46b4: Fix Travis build failure caused by Qt/KDE document...

2016-06-17 Thread Thomas Tuegel

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: ed46b468b09dd0a44450b7df348e6a572a424529
  
https://github.com/NixOS/nixpkgs/commit/ed46b468b09dd0a44450b7df348e6a572a424529
  Author: Thomas Tuegel 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/desktops/kde-5/applications-16.04/default.nix
M pkgs/desktops/kde-5/frameworks-5.22/default.nix
M pkgs/desktops/kde-5/plasma-5.6/default.nix
M pkgs/development/libraries/qt-5/5.6/default.nix

  Log Message:
  ---
  Fix Travis build failure caused by Qt/KDE documentation

The comments in the Qt/KDE packages caused a spurious Travis build
failure because they appeared to refer to ``.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Rework goPackages

2016-06-17 Thread Scott Devoid

Hi Kamil,

First thank you for working on this! Having go2nix as a tool certainly
makes packaging Go programs much easier! I don't do a lot of Nix
packaging but I do write Go software---so maybe I have a different
perspective on this. Anyhow here are some thoughts:

- Many Go software projects try to be careful to vendor their
dependencies. For example, the Caddy server does this and it works
very well. Nix only needs to record the top-level package's SHA1 and
use fetchFromGithub + buildGoPacakge [1]. No need to recursively
expose all dependencies.

- An exception to this rule are projects that make use of C or C++
linked libraries. [2] For these you would need to add explicit
packages.

- Then I take a look at Otto's Makefile and the updatedeps target [3]
and I am shocked! This is a terrible practice that the Hashicorp folks
should fix. They do things correctly with Vault so I don't see why
they can't fix it here. In any case, here go2nix is awesome since it
can effectively discover each dependency (tooling around the `go list`
command and the contents of GOPATH) and produce Nix derivations for
each component.

- However, putting all of these in a "flat" go-packages.nix seems
incorrect. At the very least, two Go programs may require different
versions of the same package. And, as you mention, there's the
question of how to consistently name these packages. This is even more
complicated since packages may be named one thing but reside somewhere
else. And some packages get "folded in" to the standard library with
subsequent Go releases. [4] Or terrible redirect "services" like
gopkg.in [5]

- What's the goal here? I would expect that Nix has packages for
'major' Go programs and tooling to make it easy to package new
programs or update releases. The tooling should be designed so that an
update to one program doesn't break or alter dependencies for other
programs. I think this implies that the tooling produces a
'go-libs.json' per-program as opposed to a single top-level
go-packages.nix file. This might cause redundant downloads of common
dependencies but that cost seems relatively minor compared to the
organizational headache that a flat-namespace would require.

~ Scott

[1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/caddy/default.nix
[2] https://golang.org/cmd/cgo
[3] https://github.com/hashicorp/otto/blob/master/Makefile#L35
[4] See golang.org/x/net/context -> net/context in go1.7
[5] http://labix.org/gopkg.in

On Fri, Jun 17, 2016 at 6:55 AM, Kamil Chmielewski  wrote:
> Hi,
>
> few days ago I started a PR called [WIP] Rework goPackages
> https://github.com/NixOS/nixpkgs/pull/16017 which is now on master and can
> leads to confusion for everyone creating goPackages before. I was also a
> little surprised how fast it was merged but I thought it was the effect of
> how many people feel the same pain as me, trying to manage or introduce new
> goPackages so there wasn't a lot of discussion there. But now it starts in
> few places and I think that this will be better place to make decisions
> about Go packaging in Nix.
>
> I want to start with the motivation which led me to this topic. Few months
> ago I wanted to introduce Otto (https://www.ottoproject.io/) to Nix. I was
> starting with Nix back then i tried to do things as they were in
> go-packages.nix.
> So I created otto as buildFromGithub[1] and use its bin output in
> all-packages.nix[2]. Next nix-build -A otto and I got 23 dependencies
> missing[3]. So I started to add dependencies manually doing  nix-build -A
> otto tens of times because each of them depends on new things that `go
> build` tells me only when I add new sources for build... [4]
> After many hours of doing nix-build and new edits in go-packages.nix I ended
> up with otto done in 400 lines of Nix [5] I don't want do maintain. Besides
> new packages I also need to change version of things that were there before,
> potentially breaking other things. I can't even image how many hours of work
> it'll cost me to update it to new version :( So there no otto in nixpkgs.
> Instead of making otto I've started go2nix[6] prototype where I want to use
> Go toolchain because it can find out all transitive dependencies in one go.
> It wasn't hard to write a prototype in Go because everthing for it is there.
> So after a minutes I could automatically generate a list of all dependencies
> that I need to build any Go binary! Next step was to generate working Nix
> expression with this list of dependencies that can be used in goPackages.
> How hard can it be? :) It turned out that it's impossible to do this reusing
> goPackages in its current state. How could I know that:
> * github.com/ugorji/go sould be ugorji.go [7]
> * gopkg.in/flosch/pongo2.v3 should be pongo2 [8]
> * google.golang.org/api should be google-api-go-client [9]
> * github.com/odeke-em/google-api-go-client shoul be
> odeke-em.google-api-go-client [10]
> * github.com/stathat/go should be stathat [11]
> ...
>
> So there were 2

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

>>> Assuming a MITM it's already game over here, the MITM doesn't even
>>> have to control one of the CAs.
>>
>> No. If you are verifying the GPG signature it is not game over. It
>> doesn't matter how you retrieve the signature and the signed file if
>> you verify them, this is assuming that the crypto primitives aren't
>> broken.
>
> Unless I misunderstood something all you are verifying is that the
> attacker's GPG signature matches the attacker's archive. This just
> gives you a false sense of security.

It doesn't really matter if the wrong signature and archive match since
you don't even have the attackers key.

>>> There is also an alternative verification method: `gpg --keyserver
>>> keys.gnupg.net --recv-keys 3D9AEBB5`. Assuming a MITM,
>>> keys.gnupg.net is accessed in clear. And generating a GPG key with
>>> the same key ID is trivial. So game over again.
>>
>> This is true. Retrieving the key is not a trivial problem. This is
>> why projects should start printing their fingerprint on all
>> promotional material and on every website and on every talk they
>> give. This way it is easier to verify that you have the right key.
>> For example some people who give talks at defcon or CCC have their
>> fingerprints on the first or last or in some cases every slide.
>>
>
> I agree. For GPG to be implemented properly, the key must be
> distributed separately from the content. The goal is to make the
> attack more expensive by forcing the attacker to compromise multiple
> communication channels. And the key fingerprint must be in the long
> form to mitigate potential collision attacks.

7B29 6212 4A73 E1E9 15E8  A7D4 7F96 C964 9CBC BF51 <- This is a fingerprint

9CBCBF51 <- This is just a short id
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 75b460: Cantata: update homepage (#16296)

2016-06-17 Thread emosenkis

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 75b460ce1b00678105f67c4e57c81952446edd6e
  
https://github.com/NixOS/nixpkgs/commit/75b460ce1b00678105f67c4e57c81952446edd6e
  Author: emosenkis 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/applications/audio/cantata/default.nix

  Log Message:
  ---
  Cantata: update homepage (#16296)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] a2b19f: libinput: 1.3.1 -> 1.3.2

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: a2b19f46608b53d03b61adf4f2e7c2c136e3184a
  
https://github.com/NixOS/nixpkgs/commit/a2b19f46608b53d03b61adf4f2e7c2c136e3184a
  Author: Alexander Ried 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/development/libraries/libinput/default.nix

  Log Message:
  ---
  libinput: 1.3.1 -> 1.3.2


  Commit: d7fc7c938cbe4ca7b967b14b01bd857d64165415
  
https://github.com/NixOS/nixpkgs/commit/d7fc7c938cbe4ca7b967b14b01bd857d64165415
  Author: Joachim Fasting 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/development/libraries/libinput/default.nix

  Log Message:
  ---
  Merge pull request #16293 from groxxda/bump/libinput

libinput: 1.3.1 -> 1.3.2


Compare: https://github.com/NixOS/nixpkgs/compare/48e45f43ac62...d7fc7c938cbe___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] f7ab8f: openjdk: 8u92b14 -> 8u102b04

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f7ab8f80a0c2c5a0e9462adac9a10c770fe88219
  
https://github.com/NixOS/nixpkgs/commit/f7ab8f80a0c2c5a0e9462adac9a10c770fe88219
  Author: Tim Steinbach 
  Date:   2016-06-16 (Thu, 16 Jun 2016)

  Changed paths:
M pkgs/development/compilers/openjdk/8.nix

  Log Message:
  ---
  openjdk: 8u92b14 -> 8u102b04


  Commit: 48e45f43ac6219a3618f995ab53233ce64170862
  
https://github.com/NixOS/nixpkgs/commit/48e45f43ac6219a3618f995ab53233ce64170862
  Author: Joachim Fasting 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/development/compilers/openjdk/8.nix

  Log Message:
  ---
  Merge pull request #16295 from NeQuissimus/openjdk8_102

openjdk: 8u92b14 -> 8u102b04


Compare: https://github.com/NixOS/nixpkgs/compare/592dcbc4bfbd...48e45f43ac62___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 54e806: syncthing: 0.13.4 -> 0.13.7

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 54e806e690bb3e124dff45ef31560cfac8f5501e
  
https://github.com/NixOS/nixpkgs/commit/54e806e690bb3e124dff45ef31560cfac8f5501e
  Author: Peter Hoeg 
  Date:   2016-06-15 (Wed, 15 Jun 2016)

  Changed paths:
M pkgs/applications/networking/syncthing/default.nix

  Log Message:
  ---
  syncthing: 0.13.4 -> 0.13.7


  Commit: d426bab7920d724bd69ef441eb51a5fa9a96a651
  
https://github.com/NixOS/nixpkgs/commit/d426bab7920d724bd69ef441eb51a5fa9a96a651
  Author: Joachim Fasting 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/applications/networking/syncthing/default.nix

  Log Message:
  ---
  Merge pull request #16283 from peterhoeg/st_0137

syncthing: 0.13.4 -> 0.13.7


Compare: https://github.com/NixOS/nixpkgs/compare/d7fc7c938cbe...d426bab7920d___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

On 17/06/16 11:40, zimbatm wrote:
> 
> I agree. For GPG to be implemented properly, the key must be distributed
> separately from the content. The goal is to make the attack more
> expensive by forcing the attacker to compromise multiple communication
> channels. And the key fingerprint must be in the long form to mitigate
> potential collision attacks.
> 

Yes, this is the trick. Put the signing key EVERYWHERE. Sign it by the
Nix maintainers and stick their keys everywhere as well. Then you verify
it with as many different channels as you like. Go to a conference, read
the website, different blog posts, ask a friend...

Just putting the key on the website besides the installer isn't much
better for the first time user, and definitely don't auto-import the key
because that will remove the benefit from repeat users as well.

signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

On Fri, 17 Jun 2016 at 16:35 Jookia <166...@gmail.com> wrote:

> On Fri, Jun 17, 2016 at 03:01:00PM +, zimbatm wrote:
> > I don't mean to say that GPG is a bad idea. It just that using SSL is a
> > better idea unless we nail the GPG bit. Not everyone is getting
> > state-sponsored attacks.
>
> TLS and GPG aren't mutually exclusive, you can use both. It's also worth
> noting
> that states aren't the only people attacking TLS: Tor exit nodes like to
> do it
> too. It does trouble me that there's no way to really verify that I have a
> copy
> of Nix that the maintainers have. Right now I check out with an unverified
> Git
> repository which isn't much better either. It'd be nice to at least try to
> have
> verification.
>

I suppose we could distribute the installation script as part of a hydra
build. That way it would be signed like the rest of the packages. It does
suppose that the build hosts aren't compromised though.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

On Fri, 17 Jun 2016 at 16:18 Yui Hirasawa  wrote:

> > Assuming a MITM it's already game over here, the MITM doesn't even have
> to
> > control one of the CAs.
>
> No. If you are verifying the GPG signature it is not game over. It
> doesn't matter how you retrieve the signature and the signed file if you
> verify them, this is assuming that the crypto primitives aren't broken.
>

Unless I misunderstood something all you are verifying is that the attacker's
GPG signature matches the attacker's archive. This just gives you a false
sense of security.

> There is also an alternative verification method: `gpg --keyserver
> > keys.gnupg.net --recv-keys 3D9AEBB5`. Assuming a MITM, keys.gnupg.net is
> > accessed in clear. And generating a GPG key with the same key ID is
> > trivial. So game over again.
>
> This is true. Retrieving the key is not a trivial problem. This is why
> projects should start printing their fingerprint on all promotional
> material and on every website and on every talk they give. This way it
> is easier to verify that you have the right key. For example some people
> who give talks at defcon or CCC have their fingerprints on the first or
> last or in some cases every slide.
>

I agree. For GPG to be implemented properly, the key must be distributed
separately from the content. The goal is to make the attack more expensive
by forcing the attacker to compromise multiple communication channels. And
the key fingerprint must be in the long form to mitigate potential
collision attacks.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

2016-06-17 Thread Jookia

On Fri, Jun 17, 2016 at 03:01:00PM +, zimbatm wrote:
> I don't mean to say that GPG is a bad idea. It just that using SSL is a
> better idea unless we nail the GPG bit. Not everyone is getting
> state-sponsored attacks.

TLS and GPG aren't mutually exclusive, you can use both. It's also worth noting
that states aren't the only people attacking TLS: Tor exit nodes like to do it
too. It does trouble me that there's no way to really verify that I have a copy
of Nix that the maintainers have. Right now I check out with an unverified Git
repository which isn't much better either. It'd be nice to at least try to have
verification.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

> Assuming a MITM it's already game over here, the MITM doesn't even have to
> control one of the CAs.

No. If you are verifying the GPG signature it is not game over. It
doesn't matter how you retrieve the signature and the signed file if you
verify them, this is assuming that the crypto primitives aren't broken.

> There is also an alternative verification method: `gpg --keyserver
> keys.gnupg.net --recv-keys 3D9AEBB5`. Assuming a MITM, keys.gnupg.net is
> accessed in clear. And generating a GPG key with the same key ID is
> trivial. So game over again.

This is true. Retrieving the key is not a trivial problem. This is why
projects should start printing their fingerprint on all promotional
material and on every website and on every talk they give. This way it
is easier to verify that you have the right key. For example some people
who give talks at defcon or CCC have their fingerprints on the first or
last or in some cases every slide.

> At that point there are still two pages of instructions to follow to get
> guix installed, with no additional security benefits.

There are security benefits in the Guix install method, they just aren't
as big as they could be. And the lenght of the Guix installation doesn't
really matter since most of it doesn't have to do with retrieving the
installer.

> I don't mean to say that GPG is a bad idea. It just that using SSL is a
> better idea unless we nail the GPG bit. Not everyone is getting
> state-sponsored attacks.

SSL is deprecated. The current standard that's in use is TLS. Attacks on
our CA system doesn't require a state-sponsored attack, it just requires
enough money to convenience a CA to give you a cert or that you yourself
have a trusted intermediate and as someone in a previous message
mentioned there are hundreds if not thousands of such organizations.
Even sub-optimal usage of GPG is still far far superior to just trusting
TLS.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

On Fri, 17 Jun 2016 at 14:56 Yui Hirasawa  wrote:

> > One improvement would be to sign the actual script with an offline key
> > but while that would be safer the current method is perfectly fine.
>
> The current method isn't fine at all.
>
> Here is a quote from the #nix channel:
>
> > kmicu: Tsutsukakushi: I told ya so… security is not a priority here.
> > Fell free to try to improve security in Nix world, but you are better
> > off with Guix. They even don’t trust compilers w/o bootstrapping from
> > the source option :)
>

Let's compare it with Guix then:

Go to https://www.gnu.org/software/guix/download/

First of all, it's not clear how to install Guix. You can download the
archive and poke inside or got to the installation instructions:
https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html

There you are instructed to fetch both the archive *and* the signature from
the same origin, over FTP. And then use gpg to check the archive against
the signature.
Assuming a MITM it's already game over here, the MITM doesn't even have to
control one of the CAs.

There is also an alternative verification method: `gpg --keyserver
keys.gnupg.net --recv-keys 3D9AEBB5`. Assuming a MITM, keys.gnupg.net is
accessed in clear. And generating a GPG key with the same key ID is
trivial. So game over again.

At that point there are still two pages of instructions to follow to get
guix installed, with no additional security benefits.

==

I don't mean to say that GPG is a bad idea. It just that using SSL is a
better idea unless we nail the GPG bit. Not everyone is getting
state-sponsored attacks.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Rework goPackages

2016-06-17 Thread Vladimír Čunát

On 06/17/2016 12:55 PM, Kamil Chmielewski wrote:
> few days ago I started a PR called [WIP] Rework goPackages
> https://github.com/NixOS/nixpkgs/pull/16017 which is now on master and
> can leads toconfusion for everyone creating goPackages before.

If that's so, a note should go to


--Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

2016-06-17 Thread Adrien Devresse

> I agree with this. A key that is trusted itself (rather then trusting a
> domain name) would be a very large security increase.

I agree too.

And this more or less the way taken by RPM / DPKG that ship their
trusted key on the client side when you install a new repository instead
of relying on any CA or PGP keyserver.


Adev



Le 17/06/2016 16:35, Kevin Cox a écrit :
> On 17/06/16 10:33, Yui Hirasawa wrote:
>>> Signing the installer script would provide only a minor increase in
>>> security (in that it would require the signing key to be compromised,
>>> rather than the nixos.org certificate). I don't object to doing that
>>> though.
>> That is quite a major increase in security actually. Compromising a key
>> that can be kept offline most of the time is a lot harder than obtaining
>> a signed certificate for the nixos.org domain. You do not have to have
>> the original nixos.org certificate to perform man-in-the-middle attack.
>>
> I agree with this. A key that is trusted itself (rather then trusting a
> domain name) would be a very large security increase.
>
>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 592dcb: Fix evaluation error in Qt/KDE packages

2016-06-17 Thread Thomas Tuegel

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 592dcbc4bfbdd98ee2f22bdea1b895db337cb770
  
https://github.com/NixOS/nixpkgs/commit/592dcbc4bfbdd98ee2f22bdea1b895db337cb770
  Author: Thomas Tuegel 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
A maintainers/scripts/fetch-kde-qt.sh
A maintainers/scripts/generate-kde-applications.sh
A maintainers/scripts/generate-kde-frameworks.sh
A maintainers/scripts/generate-kde-plasma.sh
A maintainers/scripts/generate-qt.sh
M pkgs/desktops/kde-5/applications-16.04/default.nix
A pkgs/desktops/kde-5/applications-16.04/srcs.nix
M pkgs/desktops/kde-5/frameworks-5.22/default.nix
A pkgs/desktops/kde-5/frameworks-5.22/srcs.nix
M pkgs/desktops/kde-5/plasma-5.6/default.nix
A pkgs/desktops/kde-5/plasma-5.6/srcs.nix
M pkgs/development/libraries/qt-5/5.6/default.nix
A pkgs/development/libraries/qt-5/5.6/srcs.nix

  Log Message:
  ---
  Fix evaluation error in Qt/KDE packages

For now, the source hashes will continue to be stored in the Nixpkgs
tree. The package update instructions are updated.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Malicious installation methods

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
> >>> both the tarball and the displayed hash.
> >>
> >> Hash would only ensure that there is no corruption en route, but we
> >> already have that since most TLS ciphersuites are authenticated... gotta
> >> check nixos.org ciphersuites.
> >
> > I wonder if something like this would be better perceived:
> > ...
>
> No. Just verifying a hash isn't good enough. Instead the script should
> come with a detached PGP signature.
>

The second argument could alternatively be a GPG fingerprint then. It
wouldn't protect the user from a downgrade attack though.

Did you reply to me out of the list on purpose?
>

Not on purpose. I believe it went both to you and the list though.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Malicious installation methods

> 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 user,
even more convenient than the curl | sh method since the user doesn't
have to go to the project's website to find out what exactly they are
supposed to curl and what are they supposed to pipe it to and as which
user it should be done as.

> (providing secure and easy installation)

Security is a trade-off with convenience. You have to sacrifice a bit of
one to get the other. Giving user the steps to verify the script is a
very small hit on the usability and convenience but very significant
increase for security.

> This is not a rhetorical question meant to point out that no project
> does this well. I really just don't know of one.

Anything that tells the user to just install their software with a
package manager is doing it. So, pip, cpan etc. are all better than you
in this regard.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

On 17/06/16 10:33, Yui Hirasawa wrote:
>
>> Signing the installer script would provide only a minor increase in
>> security (in that it would require the signing key to be compromised,
>> rather than the nixos.org certificate). I don't object to doing that
>> though.
> 
> That is quite a major increase in security actually. Compromising a key
> that can be kept offline most of the time is a lot harder than obtaining
> a signed certificate for the nixos.org domain. You do not have to have
> the original nixos.org certificate to perform man-in-the-middle attack.
>

I agree with this. A key that is trusted itself (rather then trusting a
domain name) would be a very large security increase.




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

On 17/06/16 10:26, Eelco Dolstra wrote:
> 
> Cargo cult security is not a priority. I wouldn't worry about "curl | bash" 
> but
> not the giant binary tarball downloaded and executed by that script (or
> equivalently, installing a binary RPM or Deb package). Signing the installer
> script would provide only a minor increase in security (in that it would 
> require
> the signing key to be compromised, rather than the nixos.org certificate). I
> don't object to doing that though.
> 

I generally agree wit this. I think moving the whole system to offline
signing would be nice but I don't think it's very urgent.

Another advantage of moving away from the CA system is that the CA
system can be bypassed if any of hundreds (thousands?) of CAs are
compromised, or if the Nix servers are compromised. Where as if it is an
"offline" key (even if it's an online PGP key it would be better). There
is a single, more difficult attack surface.

signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

>> HTTPS is not a verified channel. Our current CA system is really
>> fragile
>
> It is, but it works a lot better than the PGP web of trust in that it
> doesn't require people to get together to engage in quaint key signing
> rituals.

PGP has a web of trust but in our CA anyone with intermediate that is
trusted can impersonate anyone they want and no one would notice unless
they manually go and check who has signed the server cert. Unfortunately
we don't have anything that would work better than key signing rituals
and the CA system we have is objectively worse in every way except in
that the keys are already trusted and the user doesn't have to even know
they are there, and even this can be seen as a negative thing for
security.

> Signing the installer script would provide only a minor increase in
> security (in that it would require the signing key to be compromised,
> rather than the nixos.org certificate). I don't object to doing that
> though.

That is quite a major increase in security actually. Compromising a key
that can be kept offline most of the time is a lot harder than obtaining
a signed certificate for the nixos.org domain. You do not have to have
the original nixos.org certificate to perform man-in-the-middle attack.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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 secure and easy installation) well. Is Brew? Is
NPM? This is not a rhetorical question meant to point out that no
project does this well. I really just don't know of one.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

Hi,

On 06/17/2016 03:56 PM, Yui Hirasawa wrote:

> HTTPS is not a verified channel. Our current CA system is really fragile

It is, but it works a lot better than the PGP web of trust in that it doesn't
require people to get together to engage in quaint key signing rituals.

> Here is a quote from the #nix channel: 
> 
>> kmicu: Tsutsukakushi: I told ya so… security is not a priority here.

Cargo cult security is not a priority. I wouldn't worry about "curl | bash" but
not the giant binary tarball downloaded and executed by that script (or
equivalently, installing a binary RPM or Deb package). Signing the installer
script would provide only a minor increase in security (in that it would require
the signing key to be compromised, rather than the nixos.org certificate). I
don't object to doing that though.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] a34ec6: terra: 2016-01-06 -> 2016-06-09

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: a34ec656594a01dcddc1e121f23d60b14aed835a
  
https://github.com/NixOS/nixpkgs/commit/a34ec656594a01dcddc1e121f23d60b14aed835a
  Author: William Casarin 
  Date:   2016-06-16 (Thu, 16 Jun 2016)

  Changed paths:
M pkgs/development/compilers/terra/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  terra: 2016-01-06 -> 2016-06-09

* llvmPackages_35 -> llvmPackages_38
* static llvm no longer needed
* multiple outputs, this generates the following results:
- out/lib/terra.so
- bin/bin/terra
- dev/include/terra/*.h
- static/lib/libterra.a

Contributed with help from @joachifm


  Commit: 8e3a674305c6e726d522d8541e162f55a73fb5c6
  
https://github.com/NixOS/nixpkgs/commit/8e3a674305c6e726d522d8541e162f55a73fb5c6
  Author: Joachim Fasting 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/development/compilers/terra/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Merge pull request #16237 from jb55/terra-update-master

terra: 2016-01-06 -> 2016-06-09


Compare: https://github.com/NixOS/nixpkgs/compare/f81fc6b5aca8...8e3a674305c6___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Malicious installation methods

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 that pattern,
if it would generate less heat:

#!/bin/sh## Usage: curl-install  #fail() {
  echo "$*" >&2
  exit 1
}if [ #@ -lt 2 ]; then
  abort "missing arguments"fi

url=$1
sha256=$2

script_path=$(mktemp)
curl -o "$script_path" "$url"if [ "$sha256" != $(sha256sum
"$script_path") ]; then
  abort "Checksum don't match"fi
chmod +x "$script_path"exec $script_path



On Fri, 17 Jun 2016 at 14:58 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
> > both the tarball and the displayed hash.
>
> Hash would only ensure that there is no corruption en route, but we
> already have that since most TLS ciphersuites are authenticated... gotta
> check nixos.org ciphersuites.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Malicious installation methods

>> 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
> user to verify. That is what many projets do, and it's a three lines
> of installation instead of one.

And just because the installer is a problem doesn't mean the binary
packages couldn't also be a problem.

>>> PS. There are ways of detecthing when something is piped straight to an
>>> interpreter and thus even if someone did curl and read the output and
>>> then curled into a shell they could still get infected as serving
>>> different pages depending on the circumstances isn't all that
>>> difficult.
>>
>> This assumes https://nixos.org is already malicious - and then you shouldn't 
>> run *anything* that comes from there.
>>
>
> The problem is not *ONLY* nixos.org.
>
> Depending of your country and your environment, TLS / HTTPS alone is not
> anymore a protocol that you can trust blindly
> - https://blog.filippo.io/untrusting-an-intermediate-ca-on-os-x/
> - 
> https://yro.slashdot.org/story/15/12/08/1451239/in-kazakhstan-the-internet-backdoors-you
> - https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
>
> 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.
>
> Transforming this into a three lines installation script with a simple
> "sha256sum -c " verification would not make users run away and would
> make the project look more professional.

sha256sum won't be much use if you don't also sign the sums. Of course
you could also just detachsign the scripts as well.

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Malicious installation methods

> 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 is no corruption en route, but we
already have that since most TLS ciphersuites are authenticated... gotta
check nixos.org ciphersuites.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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 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.

However, I entirely agree with you that a cryptographic signature would
be the best way to go.

Cheers,
Adev


Le 17/06/2016 15:23, Kevin Cox a écrit :
> 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 shasum of your installer on the website and ask the user
>> to verify. That is what many projets do, and it's a three lines of
>> installation instead of one.
>>
> 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.
>
>




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] [y...@cock.li: Re: Malicious installation methods]

>> 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 builds when your system can
>> be completely infected when you install the package manager. This
>> also means that anything installed through the package manager is
>> potentially malicious as well.
>>
>>> $ curl https://nixos.org/nix/install | sh
>>

> and the distribution method is over a verified channel

HTTPS is not a verified channel. Our current CA system is really fragile
and there is a large number of advesaries who could easily acquire a
fake certificate for nixos.org. This method is only verified if you
actually check that the certificate that was used for the TLS
connection is the correct one for nixos.org, and currently you have to
do that manually. Verifying the connection to nixos.org is more work
than verifying a GPG signature.

> One improvement would be to sign the actual script with an offline key
> but while that would be safer the current method is perfectly fine.

The current method isn't fine at all.

Here is a quote from the #nix channel: 

> kmicu: Tsutsukakushi: I told ya so… security is not a priority here.
> Fell free to try to improve security in Nix world, but you are better
> off with Guix. They even don’t trust compilers w/o bootstrapping from
> the source option :)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Malicious installation methods

>> 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 from a source tarball you actually have a
chance to verify it's contents and tarballs can be signed. Webpages that
are piped straight into an interpreter cannot be signed.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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 downloaded tarball,
though. :)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] User-oriented nixpkgs documentation (was: ioquake3 on nixos)

2016-06-17 Thread Daniel Hlynskyi

Write a blog post. Though it is hard to maintain blog post content over
time, ask yourself "how long am I able to maintain this knowledge? Who
should be responsible for verifying this manual in with future changes?"

People expect manuals to be consistent with software. Every time I find
errors in docs, I am step away from using it. From this perspective
blogposts and wiki are better place to contribute unmaintained knowledge -
we don't expect them to be always correct.

Make tags, so google can find your article with "quake nix".

Just IMO, but critique accepted.
8 квіт. 2016 1:36 пп, користувач "Nikolay Amiantov"  написав:

> Hi,
>
> I want to add some documentation on how to use our ioquake3 derivation.
> This brings me to question on _where_ should I actually add it. Right
> now we have:
>
> 1. Nix manual: completely unrelated to my topic;
> 2. NixOS manual: primarily describes services and not packages and is
> NixOS-oriented, while my article can be of interest to Quake-playing Nix
> users in general;
> 3. nixpkgs manual: oriented at developers and packagers (as it itself
> points out).
>
> I would have added my article to the wiki, but AFAIK it's generally
> decided to get rid of it. So, where should I place articles like this? I
> would describe the general class of such documentation as "user-oriented
> nixpkgs manual".
>
> I have some other documentation articles in mind that I would like to
> write later (e.g. on steam-run), which go to the same category (I don't
> mean "games" ^_^).
>
> On 04/08/2016 12:28 PM, Nikolay Amiantov wrote:
> > I play ioquake3 successfully. It needs the following to work:
> >
> > 1. Extract pak0.pk3 file from the original Quake 3 Arena.
> > 2. Use Nix script like this:
> >
> > { nixpkgs ? import  { } }:
> >
> > let
> >   paks = nixpkgs.stdenv.mkDerivation {
> > name = "quake3-arena";
> > pak0 = ./baseq3/pak0.pk3; # Replace this with path to your file
> > buildCommand = ''
> >   install -D -m644 $pak0 $out/baseq3/pak0.pk3;
> > '';
> >   };
> > in nixpkgs.quake3wrapper {
> >   paks = [ paks nixpkgs.quake3pointrelease ];
> > }
> >
> > 3. Run `nix-build` on it: `nix-build script.nix`
> > 4. `result/bin/quake3` would run the game.
> >
> > This probably needs to be added to our manual and/or improved somehow.
>
> --
> Nikolay.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Malicious installation methods

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 tarballs instead.  In other words: perform the
> installation on Hydra, tar it, then provide platform-specific tars.

The installation section of the manual had info on how to install a binary
tarball directly, but this was lost accidentally. I've restored it in
f94a804cedc2bebe564e463bd2567da03a57204b.

We can also GPG-sign the installer script and/or the binary tarballs. That would
provide some protection against the case where the nixos.org webserver is
compromised.

> One interesting point is that little of the installation really requires
> root permissions.  Users could be asked to create the `/nix` directory
> and optionally a bunch of build users as root and then let the script do
> its job without root.  That way the script never needs to switch users.

This is already the case (as noted on the download page): if /nix exists and is
writable, then you don't need to have sudo root access.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nix] e95f3c: Fix test

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nix
  Commit: e95f3c44435c9f4540f684b7a9bdaecda8f3740a
  
https://github.com/NixOS/nix/commit/e95f3c44435c9f4540f684b7a9bdaecda8f3740a
  Author: Eelco Dolstra 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M tests/simple.sh

  Log Message:
  ---
  Fix test

http://hydra.nixos.org/build/36631898


  Commit: f94a804cedc2bebe564e463bd2567da03a57204b
  
https://github.com/NixOS/nix/commit/f94a804cedc2bebe564e463bd2567da03a57204b
  Author: Eelco Dolstra 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M doc/manual/installation/installing-binary.xml

  Log Message:
  ---
  Restore instructions on how to install a binary tarball

Looks like these were accidentally commented out in
9ffc4f4363d9596e2477645eab94e4140cd47c19.


Compare: https://github.com/NixOS/nix/compare/6a5f9c86f640...f94a804cedc2___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Malicious installation methods

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 shasum of your installer on the website and ask the user
> to verify. That is what many projets do, and it's a three lines of
> installation instead of one.
> 

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.




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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 user
to verify. That is what many projets do, and it's a three lines of
installation instead of one.


>> PS. There are ways of detecthing when something is piped straight to an
>> interpreter and thus even if someone did curl and read the output and
>> then curled into a shell they could still get infected as serving
>> different pages depending on the circumstances isn't all that
>> difficult.
> This assumes https://nixos.org is already malicious - and then you shouldn't 
> run *anything* that comes from there.
>

The problem is not *ONLY* nixos.org.

Depending of your country and your environment, TLS / HTTPS alone is not
anymore a protocol that you can trust blindly
- https://blog.filippo.io/untrusting-an-intermediate-ca-on-os-x/
-
https://yro.slashdot.org/story/15/12/08/1451239/in-kazakhstan-the-internet-backdoors-you
- https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning



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.

Transforming this into a three lines installation script with a simple
"sha256sum -c " verification would not make users run away and would
make the project look more professional.


Adev






Le 17/06/2016 14:07, Tomasz Kontusz a écrit :
>
> 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 any sort of recommendation for
>> the
>> user to inspect the script before running it. This completely defeats
>> the point of having reproducible builds when your system can be
>> completely infected when you install the package manager. This also
>> means that anything installed through the package manager is
>> potentially
>> malicious as well.
> 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?
>
>>> $ curl https://nixos.org/nix/install | sh
>> And this isn't made any better by the fact that you want users to run
>> the script blindly as the superuser.
>>
>>> This script requires that you have sudo access to root,
> The installer needs elevated privileges to do it's job.
>
>> 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 recommended installation method?
>
>> PS. There are ways of detecthing when something is piped straight to an
>> interpreter and thus even if someone did curl and read the output and
>> then curled into a shell they could still get infected as serving
>> different pages depending on the circumstances isn't all that
>> difficult.
> This assumes https://nixos.org is already malicious - and then you shouldn't 
> run *anything* that comes from there.
>
>> [1]: https://nixos.org/nix/download.html
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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 recommended installation
> method?

I have actually witnessed a few people (in person) who expressed
concerns about that method.  When questioned, the concerns turned out to
be unreasonable, because you are going to trust code from that server to
run as root blindly anyway, but this is one of those "evil pattern"
triggers that make security-minded people jump.  It's like seeing
"strcpy" in C code: not *necessarily* bad, but triggers the warning
bell.

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 tarballs instead.  In other words: perform the
installation on Hydra, tar it, then provide platform-specific tars.

One interesting point is that little of the installation really requires
root permissions.  Users could be asked to create the `/nix` directory
and optionally a bunch of build users as root and then let the script do
its job without root.  That way the script never needs to switch users.


Greets,
Ertugrul


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] bec28d: Remove unecessary branching on old nix versions

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: bec28d748c854abda373ca38831f4e77bc276fc1
  
https://github.com/NixOS/nixpkgs/commit/bec28d748c854abda373ca38831f4e77bc276fc1
  Author: zimbatm 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M lib/lists.nix
M lib/strings.nix
M pkgs/top-level/default.nix

  Log Message:
  ---
  Remove unecessary branching on old nix versions

All these builtins are available since 1.10 or earlier (1.10 being the
lib/minver.nix)


  Commit: f81fc6b5aca83d856cc89be113ce4dcd21e3b2b8
  
https://github.com/NixOS/nixpkgs/commit/f81fc6b5aca83d856cc89be113ce4dcd21e3b2b8
  Author: Eelco Dolstra 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M lib/lists.nix
M lib/strings.nix
M pkgs/top-level/default.nix

  Log Message:
  ---
  Merge pull request #16289 from zimbatm/old-nix-cleanup

Remove unecessary branching on old nix versions


Compare: https://github.com/NixOS/nixpkgs/compare/0902fd29d001...f81fc6b5aca8___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Malicious installation methods

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
enough to run it's software as root you should trust it enough not to
swap out the file on you.

If you are paranoid curl the script and follow the steps manually.

signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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 any sort of recommendation for
>the
>user to inspect the script before running it. This completely defeats
>the point of having reproducible builds when your system can be
>completely infected when you install the package manager. This also
>means that anything installed through the package manager is
>potentially
>malicious as well.
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?

>> $ curl https://nixos.org/nix/install | sh
>
>And this isn't made any better by the fact that you want users to run
>the script blindly as the superuser.
>
>> This script requires that you have sudo access to root,
The installer needs elevated privileges to do it's job.

>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 recommended installation method?

>PS. There are ways of detecthing when something is piped straight to an
>interpreter and thus even if someone did curl and read the output and
>then curled into a shell they could still get infected as serving
>different pages depending on the circumstances isn't all that
>difficult.
This assumes https://nixos.org is already malicious - and then you shouldn't 
run *anything* that comes from there.

>[1]: https://nixos.org/nix/download.html
>___
>nix-dev mailing list
>nix-dev@lists.science.uu.nl
>http://lists.science.uu.nl/mailman/listinfo/nix-dev

-- 
Wysłane za pomocą K-9 Mail.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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
> > 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 builds when your system can be
> > completely infected when you install the package manager. This also
> > means that anything installed through the package manager is potentially
> > malicious as well.
> >
> >> $ curl https://nixos.org/nix/install | sh
> >
>
> This has been discussed in many forms in many places. You are
> downloading code that you intend to run as root on your machine, and the
> distribution method is over a verified channel. This is no more
> dangerous then most other ways to download software that your root user
> will run.
>
> One improvement would be to sign the actual script with an offline key
> but while that would be safer the current method is perfectly fine.
>
> I know that people see `curl http...` and get all excited but, in this
> case at least, it is a sufficiently secure method.
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Malicious installation methods

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 builds when your system can be
> completely infected when you install the package manager. This also
> means that anything installed through the package manager is potentially
> malicious as well.
> 
>> $ curl https://nixos.org/nix/install | sh
> 

This has been discussed in many forms in many places. You are
downloading code that you intend to run as root on your machine, and the
distribution method is over a verified channel. This is no more
dangerous then most other ways to download software that your root user
will run.

One improvement would be to sign the actual script with an offline key
but while that would be safer the current method is perfectly fine.

I know that people see `curl http...` and get all excited but, in this
case at least, it is a sufficiently secure method.

signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 552388: diff-so-fancy: init at 0.9.3

2016-06-17 Thread Peter Simons

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 552388f8dfd185e603b2cfd6ef54696bbbd5
  
https://github.com/NixOS/nixpkgs/commit/552388f8dfd185e603b2cfd6ef54696bbbd5
  Author: Alexey Lebedeff 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/applications/version-management/git-and-tools/default.nix
A 
pkgs/applications/version-management/git-and-tools/diff-so-fancy/default.nix

  Log Message:
  ---
  diff-so-fancy: init at 0.9.3

Script was mentioned at GitHub blog -
https://github.com/blog/2188-git-2-9-has-been-released :)


  Commit: 0902fd29d0014515eecf4dde2b1f299059780e59
  
https://github.com/NixOS/nixpkgs/commit/0902fd29d0014515eecf4dde2b1f299059780e59
  Author: Peter Simons 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/applications/version-management/git-and-tools/default.nix
A 
pkgs/applications/version-management/git-and-tools/diff-so-fancy/default.nix

  Log Message:
  ---
  Merge pull request #16290 from binarin/init-diff-so-fancy

diff-so-fancy: init at 0.9.3


Compare: https://github.com/NixOS/nixpkgs/compare/03e3ef6234ff...0902fd29d001___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 03e3ef: xmonad-wrapper: link man pages instead of copying

2016-06-17 Thread Benno Fünfstück

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 03e3ef6234ff6ff4bc02f70c7c44c0a06249d14e
  
https://github.com/NixOS/nixpkgs/commit/03e3ef6234ff6ff4bc02f70c7c44c0a06249d14e
  Author: Benno Fünfstück 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/applications/window-managers/xmonad/wrapper.nix

  Log Message:
  ---
  xmonad-wrapper: link man pages instead of copying


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 2efdaa: xmonad-wrapper: link man pages of xmonadEnv

2016-06-17 Thread Benno Fünfstück

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 2efdaa948d2fcbcd37f952bb1a18c65316d5010a
  
https://github.com/NixOS/nixpkgs/commit/2efdaa948d2fcbcd37f952bb1a18c65316d5010a
  Author: Benno Fünfstück 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/applications/window-managers/xmonad/wrapper.nix

  Log Message:
  ---
  xmonad-wrapper: link man pages of xmonadEnv

This fixes #16282.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] Malicious installation methods

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 any sort of recommendation for the
user to inspect the script before running it. This completely defeats
the point of having reproducible builds when your system can be
completely infected when you install the package manager. This also
means that anything installed through the package manager is potentially
malicious as well.

> $ curl https://nixos.org/nix/install | sh

And this isn't made any better by the fact that you want users to run
the script blindly as the superuser.

> This script requires that you have sudo access to root,

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.

PS. There are ways of detecthing when something is piped straight to an
interpreter and thus even if someone did curl and read the output and
then curled into a shell they could still get infected as serving
different pages depending on the circumstances isn't all that difficult.

[1]: https://nixos.org/nix/download.html
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Rework goPackages

2016-06-17 Thread Kamil Chmielewski

Hi,

few days ago I started a PR called [WIP] Rework goPackages
https://github.com/NixOS/nixpkgs/pull/16017 which is now on master and can
leads to confusion for everyone creating goPackages before. I was also a
little surprised how fast it was merged but I thought it was the effect of
how many people feel the same pain as me, trying to manage or introduce new
goPackages so there wasn't a lot of discussion there. But now it starts in
few places and I think that this will be better place to make decisions
about Go packaging in Nix.

I want to start with the motivation which led me to this topic. Few months
ago I wanted to introduce Otto (https://www.ottoproject.io/) to Nix. I was
starting with Nix back then i tried to do things as they were in
go-packages.nix.
So I created otto as buildFromGithub[1] and use its bin output in
all-packages.nix[2]. Next nix-build -A otto and I got 23 dependencies
missing[3]. So I started to add dependencies manually doing nix-build -A
otto tens of times because each of them depends on new things that `go
build` tells me only when I add new sources for build... [4]
After many hours of doing nix-build and new edits in go-packages.nix I
ended up with otto done in 400 lines of Nix [5] I don't want do maintain.
Besides new packages I also need to change version of things that were
there before, potentially breaking other things. I can't even image how
many hours of work it'll cost me to update it to new version :( So there no
otto in nixpkgs.
Instead of making otto I've started go2nix[6] prototype where I want to use
Go toolchain because it can find out all transitive dependencies in one go.
It wasn't hard to write a prototype in Go because everthing for it is
there. So after a minutes I could automatically generate a list of all
dependencies that I need to build any Go binary! Next step was to generate
working Nix expression with this list of dependencies that can be used in
goPackages. How hard can it be? :) It turned out that it's impossible to do
this reusing goPackages in its current state. How could I know that:
* github.com/ugorji/go sould be ugorji.go [7]
* gopkg.in/flosch/pongo2.v3 should be pongo2 [8]
* google.golang.org/api should be google-api-go-client [9]
* github.com/odeke-em/google-api-go-client shoul be
odeke-em.google-api-go-client
[10]
* github.com/stathat/go should be stathat [11]
...

So there were 2 ways of dealing it:
* generate new goPackage without any imports from go-packages.nix and
abandon it completely
* change go-packages.nix into something that can be readable for something
that knows how packages are named in Go land
I thought that go-packages.nix, python-packages.nix .. says that we
want to reuse common dependencies somewhere but it should be possible to
override some of them if needed. And that was the beginning of [WIP] Rework
goPackages with go-packages.nix "converted" into libs.json that was also
influenced by temptation to make it possible to automate future updates[12].

As a troublemaker I want to involve all interested people to find out what
next moves we should do to make:
* master branch at least as usable as it was before rework
* working with Nix and Go the best experience for both Nixers and Gophers

So lets start with the first one. Most comments I see is related to
libs.json.
Does it mean we want go-packages.nix but in form that can be generated and
imported like libs.json or we don't want it at all moving all the
dependencies to separate derivations? Or maybe we want go-packages.nix as
it was before?

--
Kamil

[1]
https://github.com/kamilchm/nixpkgs/pull/3/files#diff-8631dcd3e45d5f2ceaedeb96a23bee6fR2214
[2]
https://github.com/kamilchm/nixpkgs/pull/3/files#diff-036410e9211b4336186fc613f7200b12R12219
[3]
https://gist.github.com/kamilchm/bec9483a111babafe965abcec9efb013#file-nix-build-a-otto
[4] https://gist.github.com/kamilchm/bec9483a111babafe965abcec9efb013
[5] https://github.com/kamilchm/nixpkgs/pull/3
[6] https://github.com/kamilchm/go2nix
[7]
https://github.com/kamilchm/nixpkgs/blob/otto-before/pkgs/top-level/go-packages.nix#L683
[8]
https://github.com/kamilchm/nixpkgs/blob/otto-before/pkgs/top-level/go-packages.nix#L2070
[9]
https://github.com/kamilchm/nixpkgs/blob/otto-before/pkgs/top-level/go-packages.nix#L861
[10]
https://github.com/kamilchm/nixpkgs/blob/otto-before/pkgs/top-level/go-packages.nix#L872
[11]
https://github.com/kamilchm/nixpkgs/blob/otto-before/pkgs/top-level/go-packages.nix#L2700
[12] https://github.com/NixOS/nixpkgs/pull/13819
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Persistent NixOps keys

2016-06-17 Thread 4levels

Hi Tomasz,

Thanks for another great pointer!
My own services do require the keys so I have to make them depend/require
on keys.target

I'm about to test this out, I'll keep you posted here..

Kind regards,

Erik

On Fri, Jun 17, 2016, 11:47 Tomasz Czyż  wrote:

> Erik, you also could add your load-keys service to network.target or any
> target which starts at the system start. So then you don't have to add it
> to specific apps, depends on your keys workflow.
>
> 2016-06-17 9:48 GMT+01:00 4levels <4lev...@gmail.com>:
>
>> That's probably it!
>>
>> I still need to update all service configs to have keys.target in the
>> wantedBy list.
>>
>> I read somewhere that I should also use requiredBy for it to really wait
>> untill keys.target is finished..
>>
>> Kind regards,
>>
>> Erik
>>
>> On Thu, Jun 16, 2016, 23:50 Игорь Пашев  wrote:
>>
>>> 2016-06-14 17:17 GMT+03:00 4levels <4lev...@gmail.com>:
>>> > wantedBy = [ "keys.target" ];
>>>
>>>
>>> Maybe you don't have services depending on keys.target
>>>
>>
>
>
> --
> Tomasz Czyż
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 95b896: gvolicon: c04cafb -> 31cf770

2016-06-17 Thread Benno Fünfstück

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 95b896228dfd560b76ed149ed80e12f15c60bd2f
  
https://github.com/NixOS/nixpkgs/commit/95b896228dfd560b76ed149ed80e12f15c60bd2f
  Author: Benno Fünfstück 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/tools/audio/gvolicon/default.nix

  Log Message:
  ---
  gvolicon: c04cafb -> 31cf770


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Persistent NixOps keys

2016-06-17 Thread Tomasz Czyż

Erik, you also could add your load-keys service to network.target or any
target which starts at the system start. So then you don't have to add it
to specific apps, depends on your keys workflow.

2016-06-17 9:48 GMT+01:00 4levels <4lev...@gmail.com>:

> That's probably it!
>
> I still need to update all service configs to have keys.target in the
> wantedBy list.
>
> I read somewhere that I should also use requiredBy for it to really wait
> untill keys.target is finished..
>
> Kind regards,
>
> Erik
>
> On Thu, Jun 16, 2016, 23:50 Игорь Пашев  wrote:
>
>> 2016-06-14 17:17 GMT+03:00 4levels <4lev...@gmail.com>:
>> > wantedBy = [ "keys.target" ];
>>
>>
>> Maybe you don't have services depending on keys.target
>>
>


-- 
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] af412f: disnix-module: split dysnomia's functionality into...

  Branch: refs/heads/release-16.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: af412f29c817f0789998b495e369c8abaebcda38
  
https://github.com/NixOS/nixpkgs/commit/af412f29c817f0789998b495e369c8abaebcda38
  Author: Sander van der Burg 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M nixos/modules/module-list.nix
M nixos/modules/services/misc/disnix.nix
A nixos/modules/services/misc/dysnomia.nix

  Log Message:
  ---
  disnix-module: split dysnomia's functionality into a separate module so that 
it can be used without Disnix and remove the hacky/obsolete avahi publisher

(cherry picked from commit 8fccaa901192be95f75412f12f54063196b18186)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 8fccaa: disnix-module: split dysnomia's functionality into...

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 8fccaa901192be95f75412f12f54063196b18186
  
https://github.com/NixOS/nixpkgs/commit/8fccaa901192be95f75412f12f54063196b18186
  Author: Sander van der Burg 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M nixos/modules/module-list.nix
M nixos/modules/services/misc/disnix.nix
A nixos/modules/services/misc/dysnomia.nix

  Log Message:
  ---
  disnix-module: split dysnomia's functionality into a separate module so that 
it can be used without Disnix and remove the hacky/obsolete avahi publisher


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 420b3c: git: fix perl shebangs in contrib

2016-06-17 Thread Peter Simons

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 420b3c37ef65b04ca3a84eda3d952f8b2152cd97
  
https://github.com/NixOS/nixpkgs/commit/420b3c37ef65b04ca3a84eda3d952f8b2152cd97
  Author: Alexey Lebedeff 
  Date:   2016-06-16 (Thu, 16 Jun 2016)

  Changed paths:
M pkgs/applications/version-management/git-and-tools/git/default.nix

  Log Message:
  ---
  git: fix perl shebangs in contrib

There are a lot of scripts in contrib (e.g. `diff-highlight`) that
contain perl shebang line. But `patchShebangs` is unablle to fix this
without explicitly listing `perl` in `buildInputs`.


  Commit: dddb5179c27ef6eb993437e0352b7e825785a150
  
https://github.com/NixOS/nixpkgs/commit/dddb5179c27ef6eb993437e0352b7e825785a150
  Author: Peter Simons 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/applications/version-management/git-and-tools/git/default.nix

  Log Message:
  ---
  Merge pull request #16279 from binarin/git-contrib-depends-on-perl

git: fix perl shebangs in contrib


Compare: https://github.com/NixOS/nixpkgs/compare/98096004ce31...dddb5179c27e___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 4ac742: perl-IO-Socket-SSL: 2.020 -> 2.027

2016-06-17 Thread Robert Helgesson

  Branch: refs/heads/release-16.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 4ac7425f18534a4dd0f135b3c3cf043da9b5163c
  
https://github.com/NixOS/nixpkgs/commit/4ac7425f18534a4dd0f135b3c3cf043da9b5163c
  Author: Robert Helgesson 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/top-level/perl-packages.nix

  Log Message:
  ---
  perl-IO-Socket-SSL: 2.020 -> 2.027

(cherry picked from commit e612954896f69e54b6d5a8a4dc21ecd64da72853)


  Commit: ea672e3bb84903dd2b0768f1a4ed686efef17d5a
  
https://github.com/NixOS/nixpkgs/commit/ea672e3bb84903dd2b0768f1a4ed686efef17d5a
  Author: Robert Helgesson 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/top-level/perl-packages.nix

  Log Message:
  ---
  perl-IO-Socket-SSL: fix default path to SSL certs

(cherry picked from commit 98096004ce316969e3b4494d102c1fb172b7e474)


Compare: https://github.com/NixOS/nixpkgs/compare/ca97cce179b3...ea672e3bb849___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 980960: perl-IO-Socket-SSL: fix default path to SSL certs

2016-06-17 Thread Robert Helgesson

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 98096004ce316969e3b4494d102c1fb172b7e474
  
https://github.com/NixOS/nixpkgs/commit/98096004ce316969e3b4494d102c1fb172b7e474
  Author: Robert Helgesson 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/top-level/perl-packages.nix

  Log Message:
  ---
  perl-IO-Socket-SSL: fix default path to SSL certs


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Persistent NixOps keys

2016-06-17 Thread 4levels

That's probably it!

I still need to update all service configs to have keys.target in the
wantedBy list.

I read somewhere that I should also use requiredBy for it to really wait
untill keys.target is finished..

Kind regards,

Erik

On Thu, Jun 16, 2016, 23:50 Игорь Пашев  wrote:

> 2016-06-14 17:17 GMT+03:00 4levels <4lev...@gmail.com>:
> > wantedBy = [ "keys.target" ];
>
>
> Maybe you don't have services depending on keys.target
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] ca97cc: DisnixWebService: 0.5 -> 0.6

  Branch: refs/heads/release-16.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: ca97cce179b3a4106d0ec6f3560333cdf764cef5
  
https://github.com/NixOS/nixpkgs/commit/ca97cce179b3a4106d0ec6f3560333cdf764cef5
  Author: Sander van der Burg 
  Date:   2016-06-17 (Fri, 17 Jun 2016)

  Changed paths:
M pkgs/tools/package-management/disnix/DisnixWebService/default.nix

  Log Message:
  ---
  DisnixWebService: 0.5 -> 0.6

(cherry picked from commit fcf72b82ae386bc83fd9a4bd7ed253e22ad30078)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] fcf72b: DisnixWebService: 0.5 -> 0.6