It's not strictly required, but it would mean losing out on all the binary
packages provided by the CI.
On 17 Jun 2016 20:54, "Yui Hirasawa" wrote:
> >>> True, of course. But, there is a class of software projects which will
> >>> likely never be "packaged" by package managers -
>> If you sign the script and it contains say sha512sums for the things it
>> pulls you don't have to sign them separately. It's similiar to how many
>> distributions only distribute one file with all the sums that is signed.
>
> I don't think there's no easy way for the user to verify such sums,
On 16-06-18 11:46pm, Bardur Arantsson wrote:
> On 06/18/2016 11:18 PM, Profpatsch wrote:
> >
> > The script approach is not very bad. Maybe sign it with gpg for people
> > who want to verify it.
> >
>
> Have you been following along on the thread at all? Signing the
> installer script does very
On 06/18/2016 11:18 PM, Profpatsch wrote:
>
> The script approach is not very bad. Maybe sign it with gpg for people
> who want to verify it.
>
Have you been following along on the thread at all? Signing the
installer script does very little[1] unless the bits it fetches are
themselves also
On 16-06-18 05:27pm, Michiel Leenaars wrote:
> Regarding the installer: it would be cool to have something like
> http://appimage.org, http://orbital-apps.com, http://flatpak.org or
> http://snapcraft.io instead of a shell script. That would have a SHA
> that could be verified, etc.
It would be
Hi all,
>> Is the nix root dir configurable? Would it be that horrible
>> to have /opt/nix or /var/lib/nix or something else be the nix
>> root on Debian?
> It's not strictly required, but it would mean losing out
> on all the binary packages provided by the CI.
although it would mean a Big
Yui Hirasawa writes:
> Is the nix root dir configurable? Would it be that horrible to have
> /opt/nix or /var/lib/nix or something else be the nix root on Debian?
It is, but changing it means you can't use the binary cache anymore as
all paths change.
On 06/18/2016 12:00 AM, Yui Hirasawa wrote:
>> > Because it invalidates all the store references.
> Seems like nix needs some redesign then.
It's also the upstream packages... most of them require absolute paths
to locate their files, and I don't blame them as IMHO that approach
saves some
First of all, you can install nix in another location, but then you won't
be able to use the binary cache anymore.
I thought a bit about how we could make this work:
- store the nix store physically in /var/lib/nix/store on Debian
- create a union fs in /var/lib/nix/nix-root of / and
>>> 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
>>> 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
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,
> >
> 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
>>> 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
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
>>> 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
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
>
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
> 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
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
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
>> 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
> 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
> 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
>> 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
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
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
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
> 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
>> 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
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
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
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
> >
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
34 matches
Mail list logo