> I don’t plan personally to make it a separately-maintained tool, but it
> could be interesting. More generally, getting in touch with the Git
> developers and also with other projects with similar concerns would be
> great.
That's good to know, thanks! Yup, git integration would be
great. Mea
Ludovic Courtès schreef op ma 18-07-2022 om 10:45 [+0200]:
> The model here is that users trust authorized committers. When you
> think about it, there’s no way around it, because at the end of the
> day, you’re installing software that an authorized committer added to
> the channel.
FWIW, someth
Arun Isaac schreef op di 19-07-2022 om 12:51 [+0530]:
>
> Hi Ludo,
>
> > https://doi.org/10.22152/programming-journal.org/2023/7/1
>
> This is an excellent read! Are there plans to release this git
> authentication system as a separate tool so that other non-Guix
> projects may use it easily?
Hi!
Arun Isaac skribis:
> This is an excellent read! Are there plans to release this git
> authentication system as a separate tool so that other non-Guix projects
> may use it easily?
Not really. ‘guix git authenticate’ is already usable outside and the
modules behind it are well isolated fro
Hi Ludo,
> https://doi.org/10.22152/programming-journal.org/2023/7/1
This is an excellent read! Are there plans to release this git
authentication system as a separate tool so that other non-Guix projects
may use it easily?
Thanks,
Arun
This is why things like SELinux exist, combine with separate binaries
for the functionality that impacts things outside of the store to
quickly minimize possible damage. If the binary can only create links
the possible damage is quite limited.
But the much more dangerous modification is much more
Ludovic Courtès writes:
>> My two cents: When depolying a manifest, we use `guix package -p
>> -m `, This command consists two
>> parts. Guix will first evaluate the packages specified in the manifest,
>> and build the profile. And then populate the profile to given
>> destination. The first p
Hi,
Zhu Zihao skribis:
> https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/
>
> Here's a detailed report about Marak and faker.js.
Interesting. But yeah, a Guix committer could change Guix anytime to
print “LIBERTY” (that’s very mu
Ludovic Courtès writes:
>> We have PGP sign and git commit chain to make sure the commits are
>> committed by trusted people. But it's still possible for the channel
>> owner to inject malicious code into the channel in a future commit. Like
>> what Marak Squires did in faker.js project :( or th
Hi,
Zhu Zihao skribis:
> There's still some questions to ask. I'm concerned about the safety of
> the evaluation of channel code. IIRC, there's no sandbox for the
> evaluation of package in channel. So, it's possible to inject some
> side-effect code into a channel like
>
> ```
> (define-module
Good article!
There's still some questions to ask. I'm concerned about the safety of
the evaluation of channel code. IIRC, there's no sandbox for the
evaluation of package in channel. So, it's possible to inject some
side-effect code into a channel like
```
(define-module (my channel code))
(di
Hi zimoun,
On +2022-07-04 10:21:13 +0200, zimoun wrote:
> Hi,
>
> On Sun, 03 Jul 2022 at 12:38, Bengt Richter wrote:
> >> I do not think committers are pushing code about #1, #2 or #3 that they
> >> know beforehand it will cause a problem.
> >
> > Hm, -- unless ... ? :)
> >
>
> I do not unders
Hi,
On Sun, 03 Jul 2022 at 12:38, Bengt Richter wrote:
>> I do not think committers are pushing code about #1, #2 or #3 that they
>> know beforehand it will cause a problem.
>
> Hm, -- unless ... ? :)
>
I do not understand what you mean?
>> The GPG trust level works because it is based on the
Hi,
b...@bokr.com skribis:
> I think IWBN to have some kind of trust code come with that git output,
> like gpg's 1-5 but indicating how well the committer/signer trusts
> that using the code will *not* cause a problem.
>
> I would like it if every commit had to have a code like that.
I very muc
Hi Simon, and all,
On +2022-07-01 11:21:43 +0200, zimoun wrote:
> Hi Bengt,
>
> On jeu., 30 juin 2022 at 23:37, b...@bokr.com wrote:
>
> > I think IWBN to have some kind of trust code come with that git output,
> > like gpg's 1-5 but indicating how well the committer/signer trusts
> > that using
Hi Bengt,
On jeu., 30 juin 2022 at 23:37, b...@bokr.com wrote:
> I think IWBN to have some kind of trust code come with that git output,
> like gpg's 1-5 but indicating how well the committer/signer trusts
> that using the code will *not* cause a problem.
Well, from my understanding, Guix is dea
On +2022-06-30 16:13:10 +0200, Ludovic Courtès wrote:
> Hello Guix!
>
> I’m happy to announce the publication of a refereed paper in the
> Programming journal:
>
> https://doi.org/10.22152/programming-journal.org/2023/7/1
>
> It talks about the “secure update” mechanism used for channels and h
Hello Guix!
I’m happy to announce the publication of a refereed paper in the
Programming journal:
https://doi.org/10.22152/programming-journal.org/2023/7/1
It talks about the “secure update” mechanism used for channels and how
it fits together with functional deployment, reproducible builds, a
18 matches
Mail list logo
