Re: [Nix-dev] Debugging callPackage builds?

2016-02-26 Thread Anand Patil 
... And anyway, the problem I was trying to debug turned out to be the GHC
library ID bug. :)


On Fri, Feb 26, 2016 at 10:11 AM Anand Patil <
anand.prabhakar.pa...@gmail.com> wrote:

> Never mind, figured it out: nix-shell ./nixpkgs -A
> packages.haskell.compiler.ghcjs . I was confused because nix-shell
> ./nixpkgs/pkgs/development/compilers/ghcjs was complaining that it didn't
> have default values for all the arguments.
>
> Anand
>
> On Thu, Feb 25, 2016 at 7:18 PM Anand Patil <
> anand.prabhakar.pa...@gmail.com> wrote:
>
>> Hi everyone,
>>
>> I'm trying to debug
>> https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/ghcjs/default.nix
>>  ,
>> which is a callPackage-style Nix function that expects lots of arguments.
>> Is there a quick way to get a nix-shell or other type of debugging
>> environment for such a package?
>>
>> Thanks,
>> Anand
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Signed git

2016-02-26 Thread S3 
> The binary caches are signed by the build farm, i.e. the mapping from
> expressions to binaries is "safe". That's probably the only signing ATM.
> For transporting nix expressions we offer https.
> 
> Disclaimer: I'm no security expert. And I dislike giving a false feeling
> of security.
> 
> Note that we have >70 people with push access to nixpkgs. Those are
> random people who contributed larger parts of useful stuff. Even if we
> did sign by a single key that you presumably trust, that person really
> wouldn't be able to guarantee that the contents hasn't been tampered with.
> 
> Getting everyone sign their commits would give us accountability in case
> some of us did something malicious (or github). Would that be a
> significant improvement? I'm not certain, but we might do it as the next
> step.

With signing, you would know that at least it is one of those 70 people.
Otherwise, it could be any intermediary not even related to the project.
If the original installation is tampered with, it would be very
difficult to know if anything after that point was correct.

> You can only point to something if you can sign that pointer. Just telling
> me a narinfo without any more information (that is, signing that) puts us
> back to square one.

https://github.com/NixOS/nix/issues/75

Ah, that's interesting.
I didn't know narinfos were signed.
But, that's still not quite sufficient.
git gives you the nix expression.
The nix expression builds the packages.
If it can get the cached version,
it can verify the signature, so at least
it would know the package was good in that case.
But, if it can't, then it builds the package itself.
It is building using instructions that
aren't verified.  So, it could be building
a tampered binary, since the instructions
to build it were tampered with.

If the git tags were signed, then you would
know that the instructions were good,
and would have reason to think that what
you built from it was also correct.

-- 
$_="sccc,gB1,a_oo,JosBackuSa,g11,ug1a,oscc,cBBg,JcgaBuucaB_s11_Juc_c";
while(($c,$b,$a)=m/^(.)([^,]*),(.*)$/){$_=$a;s/$c/$b/g;}
print map chr length,split /_/;



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] Debugging callPackage builds?

2016-02-26 Thread Anand Patil 
Never mind, figured it out: nix-shell ./nixpkgs -A
packages.haskell.compiler.ghcjs . I was confused because nix-shell
./nixpkgs/pkgs/development/compilers/ghcjs was complaining that it didn't
have default values for all the arguments.

Anand

On Thu, Feb 25, 2016 at 7:18 PM Anand Patil 
wrote:

> Hi everyone,
>
> I'm trying to debug
> https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/ghcjs/default.nix
>  ,
> which is a callPackage-style Nix function that expects lots of arguments.
> Is there a quick way to get a nix-shell or other type of debugging
> environment for such a package?
>
> Thanks,
> Anand
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Signed git

2016-02-26 Thread Daniel Peebles 
For anyone not following the issue tracker, there's a related discussion
going on there: https://github.com/NixOS/nix/issues/613

On Fri, Feb 26, 2016 at 7:06 AM, Eelco Dolstra 
wrote:

> Hi,
>
> On 26/02/16 11:06, Vladimír Čunát wrote:
>
> > That is, assuming the ISOs are copied to the binary cache. I briefly
> > looked for the latest 15.09 ones, and they seem not to be there:
> >  - latest channel revision: 922f03
> >  - the build: http://hydra.nixos.org/build/32068791#tabs-summary
> >  - http://cache.nixos.org/95c41wi9dqc1si96d4vhigf0p258s1mr.narinfo
>
> ISOs are not uploaded to the binary cache. Only regular packages (to be
> precise,
> builds with a Hydra build product type of "nix-build") are uploaded.
>
> --
> 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] Signed git

2016-02-26 Thread Eelco Dolstra 
Hi,

On 26/02/16 11:06, Vladimír Čunát wrote:

> That is, assuming the ISOs are copied to the binary cache. I briefly
> looked for the latest 15.09 ones, and they seem not to be there:
>  - latest channel revision: 922f03
>  - the build: http://hydra.nixos.org/build/32068791#tabs-summary
>  - http://cache.nixos.org/95c41wi9dqc1si96d4vhigf0p258s1mr.narinfo

ISOs are not uploaded to the binary cache. Only regular packages (to be precise,
builds with a Hydra build product type of "nix-build") are uploaded.

-- 
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] Signed git

2016-02-26 Thread Vladimír Čunát 
On 02/26/2016 12:16 PM, Oliver Charles wrote:
> You can only point to something if you can sign that pointer. Just
> telling me a narinfo without any more information (that is, signing
> that) puts us back to square one.

Ah, I didn't realize you wanted to sign the act of releasing another ISO
version. I assumed confirming authenticity of the ISO by our build farm
is enough.




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] Signed git

2016-02-26 Thread Oliver Charles 
You can only point to something if you can sign that pointer. Just telling
me a narinfo without any more information (that is, signing that) puts us
back to square one.

On Fri, Feb 26, 2016 at 10:06 AM Vladimír Čunát  wrote:

> On 02/26/2016 09:55 AM, Oliver Charles wrote:
> > Signed SHAs and the like give us a way to say "I am releasing this
> > version, and you have a way to check that 'I' really said it".
>
> We could point to the corresponding narinfo file. For any package
> there's a signature of the build farm.
>
> That is, assuming the ISOs are copied to the binary cache. I briefly
> looked for the latest 15.09 ones, and they seem not to be there:
>  - latest channel revision: 922f03
>  - the build: http://hydra.nixos.org/build/32068791#tabs-summary
>  - http://cache.nixos.org/95c41wi9dqc1si96d4vhigf0p258s1mr.narinfo
>
> --Vladimir
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Fwd: Fwd: Wiki is dead

2016-02-26 Thread Domen Kožar 
Heck, even Apple uses it: https://github.com/apple/swift/tree/master/docs

On Fri, Feb 26, 2016 at 10:05 AM, Freddy Rietdijk 
wrote:

> It makes sense not to have multiple formats inside a single document. As
> Eelco mentioned, it makes it harder to move around fragments, and, as I
> experienced now by using the `toDocbook` function, you still end up with
> XML errors. Therefore, instead of having to debug errors related to one
> format you now have to do so for two.
>
> What format then? Is there a single format that would fit? Should there be
> a single format for all our documentation? I actually don't think that's
> necessary. No, we better not have multiple formats in a single document.
> But how about multiple documents, with each possibly having another format?
>
> We have to think about what type of documentation we need, who each type
> is meant for, and actually also who would write that documentation. I think
> we are going to need multiple documents, as we have now, but reorganized.
>
> The most relevant one for many of us from the contributor point of view is
> going to be a User Guide, which the way I see it, would contain reference
> material to specific items in Nixpkgs (modules, functions, ...) and
> introductions. Many people should contribute to this guide, and
> contributing to it should therefore be sufficiently accessible.
>
> If we now consider formats again then Commonmark is very accessible,
> almost everyone knows it. Being a well-specified dialect of Markdown it
> doesn't suffer from ambiguity between implementations. However, it still
> lacks one important feature: references to sections. You cannot write a
> manual without internal references.
>
> Sphinx with reStructuredText has this feature, and many others that are
> also covered by Docbook but without the verbosity that comes with it.
> Furthermore, the step from Commonmark/Markdown to reStructuredText is
> small. Markdown is close to being valid rST.
>
>
>
> On Fri, Feb 26, 2016 at 9:29 AM, Vladimír Čunát  wrote:
>
>> On 02/25/2016 01:39 PM, zimbatm wrote:
>> > The output file wasn't exactly right, I had to replace `> > id="something">` to `` tags and wrap it in a  tag.
>>
>> That's because pandoc uses an older version of docbook where some tags
>> are different. (IIRC I looked a few months ago and it didn't support the
>> newer one yet.)
>>
>>
>>
>> ___
>> 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] Signed git

2016-02-26 Thread Vladimír Čunát 
On 02/26/2016 09:55 AM, Oliver Charles wrote:
> Signed SHAs and the like give us a way to say "I am releasing this
> version, and you have a way to check that 'I' really said it".

We could point to the corresponding narinfo file. For any package
there's a signature of the build farm.

That is, assuming the ISOs are copied to the binary cache. I briefly
looked for the latest 15.09 ones, and they seem not to be there:
 - latest channel revision: 922f03
 - the build: http://hydra.nixos.org/build/32068791#tabs-summary
 - http://cache.nixos.org/95c41wi9dqc1si96d4vhigf0p258s1mr.narinfo

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

[Nix-dev] Fwd: Fwd: Wiki is dead

2016-02-26 Thread Freddy Rietdijk 
It makes sense not to have multiple formats inside a single document. As
Eelco mentioned, it makes it harder to move around fragments, and, as I
experienced now by using the `toDocbook` function, you still end up with
XML errors. Therefore, instead of having to debug errors related to one
format you now have to do so for two.

What format then? Is there a single format that would fit? Should there be
a single format for all our documentation? I actually don't think that's
necessary. No, we better not have multiple formats in a single document.
But how about multiple documents, with each possibly having another format?

We have to think about what type of documentation we need, who each type is
meant for, and actually also who would write that documentation. I think we
are going to need multiple documents, as we have now, but reorganized.

The most relevant one for many of us from the contributor point of view is
going to be a User Guide, which the way I see it, would contain reference
material to specific items in Nixpkgs (modules, functions, ...) and
introductions. Many people should contribute to this guide, and
contributing to it should therefore be sufficiently accessible.

If we now consider formats again then Commonmark is very accessible, almost
everyone knows it. Being a well-specified dialect of Markdown it doesn't
suffer from ambiguity between implementations. However, it still lacks one
important feature: references to sections. You cannot write a manual
without internal references.

Sphinx with reStructuredText has this feature, and many others that are
also covered by Docbook but without the verbosity that comes with it.
Furthermore, the step from Commonmark/Markdown to reStructuredText is
small. Markdown is close to being valid rST.



On Fri, Feb 26, 2016 at 9:29 AM, Vladimír Čunát  wrote:

> On 02/25/2016 01:39 PM, zimbatm wrote:
> > The output file wasn't exactly right, I had to replace ` > id="something">` to `` tags and wrap it in a  tag.
>
> That's because pandoc uses an older version of docbook where some tags
> are different. (IIRC I looked a few months ago and it didn't support the
> newer one yet.)
>
>
>
> ___
> 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] Signed git

2016-02-26 Thread Oliver Charles 
I don't think S3 is looking for accountability but reproducibility. With
nothing signed it's unclear what you should really be expecting for the
release ISOs. Signed SHAs and the like give us a way to say "I am releasing
this version, and you have a way to check that 'I' really said it".

On Fri, Feb 26, 2016 at 8:51 AM Vladimír Čunát  wrote:

> On 02/26/2016 08:19 AM, S3 wrote:
> > So, as far as I can tell, nothing is signed.
>
> The binary caches are signed by the build farm, i.e. the mapping from
> expressions to binaries is "safe". That's probably the only signing ATM.
> For transporting nix expressions we offer https.
>
> Disclaimer: I'm no security expert. And I dislike giving a false feeling
> of security.
>
> Note that we have >70 people with push access to nixpkgs. Those are
> random people who contributed larger parts of useful stuff. Even if we
> did sign by a single key that you presumably trust, that person really
> wouldn't be able to guarantee that the contents hasn't been tampered with.
>
> Getting everyone sign their commits would give us accountability in case
> some of us did something malicious (or github). Would that be a
> significant improvement? I'm not certain, but we might do it as the next
> step.
>
> --Vladimir
>
>
> ___
> 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] Signed git

2016-02-26 Thread Vladimír Čunát 
On 02/26/2016 08:19 AM, S3 wrote:
> So, as far as I can tell, nothing is signed.

The binary caches are signed by the build farm, i.e. the mapping from
expressions to binaries is "safe". That's probably the only signing ATM.
For transporting nix expressions we offer https.

Disclaimer: I'm no security expert. And I dislike giving a false feeling
of security.

Note that we have >70 people with push access to nixpkgs. Those are
random people who contributed larger parts of useful stuff. Even if we
did sign by a single key that you presumably trust, that person really
wouldn't be able to guarantee that the contents hasn't been tampered with.

Getting everyone sign their commits would give us accountability in case
some of us did something malicious (or github). Would that be a
significant improvement? I'm not certain, but we might do it as the next
step.

--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] Fwd: Wiki is dead

2016-02-26 Thread Vladimír Čunát 
On 02/25/2016 01:39 PM, zimbatm wrote:
> The output file wasn't exactly right, I had to replace ` id="something">` to `` tags and wrap it in a  tag.

That's because pandoc uses an older version of docbook where some tags
are different. (IIRC I looked a few months ago and it didn't support the
newer one yet.)




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