Re: [Nix-dev] end-of-life kernels
On Mon, Nov 19, 2012 at 08:18:52AM +0100, Mathijs Kwik wrote: Sure, no hurries. Let's say we wait a month or so, 3.7 will be out too. I will then ask again about 3.5 So do we all agree on the other ones being obsolete? As for me, for all I remember, yes. PS: I feel a bit awkward for bringing this up and scheduling a deadline. Who gave me the right to act like this and drive decision-making? I'm not even a kernel maintainer! I think you've done it in a good way. How would we know, otherwise, if your ideas have most support? Thank you, Lluís. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fetchgit - why sha256 protection?
Hi, On 19/11/12 07:11, Marc Weber wrote: Isn't it enough to depend on the git's hash value, No, because Nix's fixed-output derivation feature requires a md5/sha1/sha256 hash of the expected contents. -- 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] end-of-life kernels
Hi, On 18/11/12 20:58, Mathijs Kwik wrote: Indeed I didn't think about 2.6.35 being our current headers, so indeed we should keep 2.6.35 until stdenv-upgrades. FWIW, the stdenv branch already uses Linux 3.5.x for the kernel headers. -- 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] fetchgit - why sha256 protection?
Excerpts from Eelco Dolstra's message of Mon Nov 19 11:01:39 +0100 2012: No, because Nix's fixed-output derivation feature requires a md5/sha1/sha256 hash of the expected contents. I know what the current implementation requires. Just wondering whether this should be relaxed for git (like) VCS sources, because they naturally have a hash. I mean why run nix-prefetch git if using url and git commit hash could be enough? If you don't trust builders, fetching git sources is that common that it could even be built into the nix tool. My goal is to simplify installing packages from other sub universes such as ruby. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fetchgit - why sha256 protection?
Hi, On 19/11/12 11:25, Marc Weber wrote: Excerpts from Eelco Dolstra's message of Mon Nov 19 11:01:39 +0100 2012: No, because Nix's fixed-output derivation feature requires a md5/sha1/sha256 hash of the expected contents. I know what the current implementation requires. Just wondering whether this should be relaxed for git (like) VCS sources, because they naturally have a hash. No. fetchgit won't work if it's not a fixed-output derivation, because it won't necessarily have network access (it might run in a chroot). -- 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] fetchgit - why sha256 protection?
Excerpts from Eelco Dolstra's message of Mon Nov 19 11:36:00 +0100 2012: No. fetchgit won't work if it's not a fixed-output derivation, because it won't necessarily have network access (it might run in a chroot). Again: I'm not talking about the current state. I'm aware about how it works. I'm talking about: Does it make sense to introduce a special fixed hash for git repos or what about implementing git checkouts natively so that passing the git's hash is enough? git sources are very common today. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fetchgit - why sha256 protection?
- Original message - Excerpts from Eelco Dolstra's message of Mon Nov 19 11:36:00 +0100 2012: No. fetchgit won't work if it's not a fixed-output derivation, because it won't necessarily have network access (it might run in a chroot). Again: I'm not talking about the current state. I'm aware about how it works. I'm talking about: Does it make sense to introduce a special fixed hash for git repos or what about implementing git checkouts natively so that passing the git's hash is enough? git sources are very common today. True, simplification sounds like a good idea. Marc Weber ___ 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] fetchgit - why sha256 protection?
Is it terribly difficult to run nix-prefetch-git? Built-in vcs-specific support doesn't strike me as simplification. On Nov 19, 2012, at 7:10 AM, Joachim Schiele j...@lastlog.de wrote: - Original message - Excerpts from Eelco Dolstra's message of Mon Nov 19 11:36:00 +0100 2012: No. fetchgit won't work if it's not a fixed-output derivation, because it won't necessarily have network access (it might run in a chroot). Again: I'm not talking about the current state. I'm aware about how it works. I'm talking about: Does it make sense to introduce a special fixed hash for git repos or what about implementing git checkouts natively so that passing the git's hash is enough? git sources are very common today. True, simplification sounds like a good idea. Marc Weber ___ 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 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fetchgit - why sha256 protection?
Could fetchgit handle that on its own though? Also, at least for github, if you want to install a specific tag, which isn't always the case, you can link to the .zip copy of it from the github page. /M Shea Levy s...@shealevy.com writes: Is it terribly difficult to run nix-prefetch-git? Built-in vcs-specific support doesn't strike me as simplification. On Nov 19, 2012, at 7:10 AM, Joachim Schiele j...@lastlog.de wrote: - Original message - Excerpts from Eelco Dolstra's message of Mon Nov 19 11:36:00 +0100 2012: No. fetchgit won't work if it's not a fixed-output derivation, because it won't necessarily have network access (it might run in a chroot). Again: I'm not talking about the current state. I'm aware about how it works. I'm talking about: Does it make sense to introduce a special fixed hash for git repos or what about implementing git checkouts natively so that passing the git's hash is enough? git sources are very common today. True, simplification sounds like a good idea. Marc Weber ___ 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 ___ 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] end-of-life kernels
For the record, I still use 2.6.35 which is the newest kernel supporting BLCR presently available in NixoOS (BLCR needs kernels = 2.6.38). By the way, for what I can say, this makes NixOS the only distribution which currently supports easily BLCR (just add two lines in configuration.nix). Seems that the development of BLCR has been resumed recently, but it still difficult to predict when there will be a new version that supports 3.x.y kernels. M. 2012/11/19 Eelco Dolstra eelco.dols...@logicblox.com: Hi, On 18/11/12 20:58, Mathijs Kwik wrote: Indeed I didn't think about 2.6.35 being our current headers, so indeed we should keep 2.6.35 until stdenv-upgrades. FWIW, the stdenv branch already uses Linux 3.5.x for the kernel headers. -- 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-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fetchgit - why sha256 protection?
Excerpts from Shea Levy's message of Mon Nov 19 13:38:37 +0100 2012: Is it terribly difficult to run nix-prefetch-git? YES: I'm talking about such configurations: http://gembundler.com/ And here you have git repo and hash. Trying to semi automatically package such things requires much overhead if you have to prefetch everything to get a sha256 hash. I'm not talking about the one project you do package once in a year. I'm talking about 20 small ruby gem packages you need to get some bleeding edge code working. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] end-of-life kernels
Marco Maggesi magg...@math.unifi.it writes: For the record, I still use 2.6.35 which is the newest kernel supporting BLCR presently available in NixoOS (BLCR needs kernels = 2.6.38). By the way, for what I can say, this makes NixOS the only distribution which currently supports easily BLCR (just add two lines in configuration.nix). Seems that the development of BLCR has been resumed recently, but it still difficult to predict when there will be a new version that supports 3.x.y kernels. We will keep 2.6.35 for now and it will become the only 2.6.x version. Mainly because our current default kernel-headers version is 2.6.35 as well. So in the short term, you're fine. After next stdenv-upgrades-merge however, it seems 3.5.x will be chosen for the headers, which might cause problems for older kernels. Also, I would like to stabilize on long-term-supported kernels, which means 2.6.32 or 2.6.34 in the 2.6.x range. To combat the headers-problem, we can add a headers-compat/headers-2.6 package and have the system use those if the chosen kernel is lower than our default (3.4 or 3.6 probably). This will cause rebuilds for almost every other package, and probably hydra will not produce binaries for systems that want to stay on 2.6, so it will take some more building-from-source, but at least it keeps the possibility to run older kernels open. I think that's a good trade-off. M. 2012/11/19 Eelco Dolstra eelco.dols...@logicblox.com: Hi, On 18/11/12 20:58, Mathijs Kwik wrote: Indeed I didn't think about 2.6.35 being our current headers, so indeed we should keep 2.6.35 until stdenv-upgrades. FWIW, the stdenv branch already uses Linux 3.5.x for the kernel headers. -- 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-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] fetchgit - why sha256 protection?
Marc Weber marco-owe...@gmx.de writes: Excerpts from Shea Levy's message of Mon Nov 19 13:38:37 +0100 2012: Is it terribly difficult to run nix-prefetch-git? YES: I'm talking about such configurations: http://gembundler.com/ And here you have git repo and hash. Trying to semi automatically package such things requires much overhead if you have to prefetch everything to get a sha256 hash. I'm not talking about the one project you do package once in a year. I'm talking about 20 small ruby gem packages you need to get some bleeding edge code working. Have you looked at Shea's npm2nix utility for node.js packages? It's really not that big/scary. Just give it the name of an npm package and it outputs a nix expression (including sha256) for that package, including its dependencies. A similar solution for rubygems would probably not be too hard. As rubygems itself is written in ruby, you can probably plug in to its dependency resolution and downloading capabilities so you can focus on generating the sha256 and the nix expression. Marc Weber ___ 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] end-of-life kernels
On Mon, Nov 19, 2012 at 02:26:00PM +0100, Mathijs Kwik wrote: Marco Maggesi magg...@math.unifi.it writes: For the record, I still use 2.6.35 which is the newest kernel supporting BLCR presently available in NixoOS (BLCR needs kernels = 2.6.38). By the way, for what I can say, this makes NixOS the only distribution which currently supports easily BLCR (just add two lines in configuration.nix). Seems that the development of BLCR has been resumed recently, but it still difficult to predict when there will be a new version that supports 3.x.y kernels. We will keep 2.6.35 for now and it will become the only 2.6.x version. Mainly because our current default kernel-headers version is 2.6.35 as well. So in the short term, you're fine. After next stdenv-upgrades-merge however, it seems 3.5.x will be chosen for the headers, which might cause problems for older kernels. Also, I would like to stabilize on long-term-supported kernels, which means 2.6.32 or 2.6.34 in the 2.6.x range. To combat the headers-problem, we can add a headers-compat/headers-2.6 package and have the system use those if the chosen kernel is lower than our default (3.4 or 3.6 probably). This will cause rebuilds for almost every other package, and probably hydra will not produce binaries for systems that want to stay on 2.6, so it will take some more building-from-source, but at least it keeps the possibility to run older kernels open. I think that's a good trade-off. As for glibc, the glibc has to be told the minimum kernel version to build for. It will use not all syscalls available in the headers, but only those which match the 'configure' argument requirement. But I imagine Eelco wants glibc to be built for 3.5 kernels or above. In trunk we have glibc using an absurdly low kernel, and I think it ends up not having 'fstatat' making proper direct syscalls or something like that. Regards, Lluís. 2012/11/19 Eelco Dolstra eelco.dols...@logicblox.com: Hi, On 18/11/12 20:58, Mathijs Kwik wrote: Indeed I didn't think about 2.6.35 being our current headers, so indeed we should keep 2.6.35 until stdenv-upgrades. FWIW, the stdenv branch already uses Linux 3.5.x for the kernel headers. -- 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-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 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] end-of-life kernels
Lluís Batlle i Rossell vi...@viric.name writes: On Mon, Nov 19, 2012 at 02:26:00PM +0100, Mathijs Kwik wrote: Marco Maggesi magg...@math.unifi.it writes: For the record, I still use 2.6.35 which is the newest kernel supporting BLCR presently available in NixoOS (BLCR needs kernels = 2.6.38). By the way, for what I can say, this makes NixOS the only distribution which currently supports easily BLCR (just add two lines in configuration.nix). Seems that the development of BLCR has been resumed recently, but it still difficult to predict when there will be a new version that supports 3.x.y kernels. We will keep 2.6.35 for now and it will become the only 2.6.x version. Mainly because our current default kernel-headers version is 2.6.35 as well. So in the short term, you're fine. After next stdenv-upgrades-merge however, it seems 3.5.x will be chosen for the headers, which might cause problems for older kernels. Also, I would like to stabilize on long-term-supported kernels, which means 2.6.32 or 2.6.34 in the 2.6.x range. To combat the headers-problem, we can add a headers-compat/headers-2.6 package and have the system use those if the chosen kernel is lower than our default (3.4 or 3.6 probably). This will cause rebuilds for almost every other package, and probably hydra will not produce binaries for systems that want to stay on 2.6, so it will take some more building-from-source, but at least it keeps the possibility to run older kernels open. I think that's a good trade-off. As for glibc, the glibc has to be told the minimum kernel version to build for. It will use not all syscalls available in the headers, but only those which match the 'configure' argument requirement. But I imagine Eelco wants glibc to be built for 3.5 kernels or above. As 3.5 is dead, we should probably choose 3.4 or 3.6. In trunk we have glibc using an absurdly low kernel, and I think it ends up not having 'fstatat' making proper direct syscalls or something like that. Upgrading this to a recent 3.4+ level sounds like a good idea. Keeping an additional low/compat target around (headers + glibc minimum for 2.6.32) sounds like a good thing too, with the consequence that if you want to use it, you need to compile a lot from source. Sounds like a good trade-off. I suspect most uses for these lower kernel versions to be related to specialized hardware or virtual machine targets, probably not needing big X11 / desktop stuff, so it's not too bad. Regards, Lluís. 2012/11/19 Eelco Dolstra eelco.dols...@logicblox.com: Hi, On 18/11/12 20:58, Mathijs Kwik wrote: Indeed I didn't think about 2.6.35 being our current headers, so indeed we should keep 2.6.35 until stdenv-upgrades. FWIW, the stdenv branch already uses Linux 3.5.x for the kernel headers. -- 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-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 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] end-of-life kernels
Hi, On 19/11/12 14:39, Lluís Batlle i Rossell wrote: As for glibc, the glibc has to be told the minimum kernel version to build for. It will use not all syscalls available in the headers, but only those which match the 'configure' argument requirement. But I imagine Eelco wants glibc to be built for 3.5 kernels or above. Stdenv has --enable-kernel=2.6.35. -- 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] end-of-life kernels
On Mon, Nov 19, 2012 at 03:25:08PM +0100, Eelco Dolstra wrote: Hi, On 19/11/12 14:39, Lluís Batlle i Rossell wrote: As for glibc, the glibc has to be told the minimum kernel version to build for. It will use not all syscalls available in the headers, but only those which match the 'configure' argument requirement. But I imagine Eelco wants glibc to be built for 3.5 kernels or above. Stdenv has --enable-kernel=2.6.35. Do you favour a higher value? In pair to the headers, for example. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] end-of-life kernels
Hi, On 19/11/12 15:28, Lluís Batlle i Rossell wrote: But I imagine Eelco wants glibc to be built for 3.5 kernels or above. Stdenv has --enable-kernel=2.6.35. Do you favour a higher value? Is there a good reason for a higher value? Certainly it can't be higher than 3.2 since that's our default kernel. And of course people may well want to run Nixpkgs on Linux distributions that have much older kernels. -- 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] end-of-life kernels
On Mon, Nov 19, 2012 at 3:37 PM, Eelco Dolstra eelco.dols...@logicblox.com wrote: Hi, On 19/11/12 15:28, Lluís Batlle i Rossell wrote: But I imagine Eelco wants glibc to be built for 3.5 kernels or above. Stdenv has --enable-kernel=2.6.35. Do you favour a higher value? Is there a good reason for a higher value? Certainly it can't be higher than 3.2 since that's our default kernel. And of course people may well want to run Nixpkgs on Linux distributions that have much older kernels. I propose introducing additional glibc-26compat and headers-26compat packages for these older kernels. I understand the effect of using those is recompiling most from scratch, but as I've already mentioned, I suspect the use cases for these older kernels to be mostly related to small/targeted systems or quick vm-test-runs on a bunch of kernels, not entire desktops/servers. Also, these systems probably won't need weekly update cycles, so these compiles are limited. We should not let those cases influence the defaults too much. I'd say on every stdenv-merge, we upgrade --enable-kernel and the default headers to the version of the previous default kernel (that would be 3.2 next time). This way, people can keep on running with the previous default for some time after a merge. For anyone wanting to use an older kernel, they can switch their glibc/headers to the 2.6-compat versions (probably 2.6.32) and do some more compiling themselves. Perhaps hydra can do some minimal profile (CLI and base system only) for the compat builds. -- 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-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] end-of-life kernels
On Mon, Nov 19, 2012 at 03:37:45PM +0100, Eelco Dolstra wrote: Hi, On 19/11/12 15:28, Lluís Batlle i Rossell wrote: But I imagine Eelco wants glibc to be built for 3.5 kernels or above. Stdenv has --enable-kernel=2.6.35. Do you favour a higher value? Is there a good reason for a higher value? Certainly it can't be higher than 3.2 since that's our default kernel. And of course people may well want to run Nixpkgs on Linux distributions that have much older kernels. There is a reason for one higher than the current trunk value: performance (fstatat implemented in kernel, instead of a userland trick). Whether there is a reason for a value *over 2.6.35*, I don't know any now, but it may very well be the same, performance. A glance at glibc code enabled after 2.6.35 should give an idea. Regards, Lluís. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fetchgit - why sha256 protection?
A similar solution for rubygems would probably not be too hard. As rubygems itself is written in ruby, you can probably plug in to its dependency resolution and downloading capabilities so you can focus on generating the sha256 and the nix expression. If you still haven't got it: I worte nixpkgs-ruby-overlay which already does it. I also wrote hack-nix packaging all hackage - and I did so after having disregarder a 80% working attempt doing it the nodejs way. I'm looking for packaging fast changing dev versions of packages. And then I don't want to wait for any double fetches. I want to give code a try. I know what I want and why. I accept that the nix community eventually things differently about this. So this may just end up being another patch in my github repos. Maybe I have to use standard ubuntu distribution cause cause I may not have time to finish all this in time (yet) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fetchgit - why sha256 protection?
Excerpts from Eelco Dolstra's message of Mon Nov 19 16:31:26 +0100 2012:
Why would you need a double fetch? After running fetchgit, the Git tree is
in
the Nix store and shouldn't be downloaded again unless you do a garbage
collect
in between.
You're right about this.
I want to make bundler (which dynamically fetches updates for
dependencies of ruby packages) use the nix store to share git sources
and gem install results.
nixpkgs-ruby-overlay gets the job done, and I could manually package all
git sources additionally to the packages found on rubyforge. It just
takes too long.
I want to work like other ruby using people do:
bundle update (fetch all dependencies, and if this was done previously reuse
store paths)
Of course running nix-prefetch-git is an option, however checking
whether a store path representing { url = ..; hash = .. } already exists
is harder. If you run nix-prefetch-git twice it will fetch twice
(waste). I haven't looked for options.
If nix could handle this, I could just create a .nix file and I'd always
get what I want: the source - if it exists I would not have to bother at
all.
About changeroot builds: You're right. So mabye a hacky
mkDerivation {
allownetwork = true;
}
would do. It could be used for such cases. Why should it be allowed?
If a programmer wants to shoot himself into the food, you can't prevent
him doing so. Thus the goal should be making it hard to do it by
accident. And this property still holds if allownetwork = true or such
existed.
So comment on whether you see huge security risks using git url and
git's hash only.
Also mind that I don't say that sha256 checks for fetchgit should no
longer be used. I just think its not worth bothering for use cases where
other tools neither do (such as bundler for ruby) - they don't even
bother to use the full git hash length (which is bad IMHO).
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fetchgit - why sha256 protection?
Of course running nix-prefetch-git is an option, however checking
whether a store path representing { url = ..; hash = .. } already exists
is harder. If you run nix-prefetch-git twice it will fetch twice
(waste). I haven't looked for options.
nix-store --check-validity $(nix-store -q --outputs $(nix-instantiate
expression.nix -A src))
?
Also, I do use fresh checkouts as src for various Nix expressions. I
just added a repository set to chroot-accessible locations and do what
you say (telling only git hashes to Nix).
If nix could handle this, I could just create a .nix file and I'd always
get what I want: the source - if it exists I would not have to bother at
all.
So comment on whether you see huge security risks using git url and
git's hash only.
It is not so much security risks as it is about special case being a
separate source of bugs.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
