I'm responding to my own message here to give a follow-up on my
progress:
On Wed, Jun 11, 2025 at 04:41:16PM +0300, Efraim Flashner wrote:
> (ins)efraim@3900XT ~/workspace/guix$ time ./pre-inst-env guix weather -m
> ./etc/manifests/release.scm
> computing 258 package derivations for x86_64-linu
Hi,
Ludovic Courtès writes:
> /gnu/store/44pj16b5fmpaqdkx9l732pnn7f1aq1bp-gnutls-3.7.7.tar.xz
> --8<---cut here---end--->8---
>
> Could it be that this person had disabled substitutes?
Definitely, substitutes aren't enabled by default on foreign distros,
an
instead of 404 for the mirror pages. That means people end
up with HTML file downloaded.
This is solved for latest Guix, but not for the release!
Moreover, there is no good mechanism to disable mirrors like that,
leaving people with no good options to update to newer Guix version.
This is because
On Wed, Feb 19, 2025 at 02:06:43PM -0800, Vagrant Cascadian wrote:
> On 2025-02-15, Vagrant Cascadian wrote:
> > On 2025-02-11, Efraim Flashner wrote:
> >> We discussed the next release during Guix Days and I volunteered to lead
> >> the effort.
> ...
> > I may
ings merged (in fact, the glibc change is not
“ungraftable” in the trivial way because it uses ‘git-fetch’, which
would cause circular dependencies on old daemons).
> I agree that we need to do an ungrafting run before a release but I'm
> not sure we're at the pre-release ungraft yet. A
On Wed, Feb 19, 2025 at 02:06:43PM -0800, Vagrant Cascadian wrote:
> On 2025-02-15, Vagrant Cascadian wrote:
> > On 2025-02-11, Efraim Flashner wrote:
> >> We discussed the next release during Guix Days and I volunteered to lead
> >> the effort.
> ...
> > I may
eeds to be tweaked to exclude the
glibc graft. I agree that we need to do an ungrafting run before a
release but I'm not sure we're at the pre-release ungraft yet. An
ungraft run in general would be a good thing.
--
Efraim Flashner אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7
On 2025-02-19, Vagrant Cascadian wrote:
> On 2025-02-15, Vagrant Cascadian wrote:
>> On 2025-02-11, Efraim Flashner wrote:
>>> We discussed the next release during Guix Days and I volunteered to lead
>>> the effort.
> ...
>> I may just make an attempt at makin
as one
cannot freely share it without fear of undue legal burdens...
At least, that is my entirely not-a-lawyer concern...
Since this is only shipped in this form whe running "make dist"
... well, seems relevent for the release process. :)
live well,
vagrant
signature.asc
Description: PGP signature
On 2025-02-15, Vagrant Cascadian wrote:
> On 2025-02-11, Efraim Flashner wrote:
>> We discussed the next release during Guix Days and I volunteered to lead
>> the effort.
...
> I may just make an attempt at making a git snapshot or something, which
> I did once in th
Hello,
I think something we need to do urgently is to run an ungrafting
process - grafting takes a considerable amount of time when updating my
system now, and I suppose it will also waste a bit of space. We should
not burden the installation process with it.
Did we not have a jobset on ci to aut
Hi Efraim,
Efraim Flashner skribis:
> The short version:
>
> * We need a tagged release so we can update the version in Debian and
> other distros, in CI systems, etc.
> * We need a newer point-in-time for the installer.
> * A new release increases interest in the project.
On 2025-02-11, Efraim Flashner wrote:
> We discussed the next release during Guix Days and I volunteered to lead
> the effort.
Thanks for working on it!
> The short version:
>
> * We need a tagged release so we can update the version in Debian and
> other distros, in CI sys
We discussed the next release during Guix Days and I volunteered to lead
the effort.
The short version:
* We need a tagged release so we can update the version in Debian and
other distros, in CI systems, etc.
* We need a newer point-in-time for the installer.
* A new release increases interest
e is a
>>> must."
>
> I agree that’s a problem.
>
>> Indeed, at least for the person running 'make release'.
>
> Right. We could perhaps avoid that by ensuring ci.guix builds all the
> relevant artifacts. It’s already set up to do that anyway, but the
&
Hi,
Maxim Cournoyer skribis:
> Greg Hogan writes:
>
>> On Wed, Dec 18, 2024 at 11:49 AM Ludovic Courtès wrote:
>>> As has been discussed multiple times at the Guix Days and on this list
>>> (I think?), I believe what we need is a release team with rotating
>&g
Hi,
Maxim Cournoyer skribis:
> Greg Hogan writes:
>
>> On Wed, Dec 18, 2024 at 12:43 PM Suhail Singh
>> wrote:
>>>
>>> Suhail Singh writes:
>>>
>>> > The issue, as I see it, is the time commitment required from the
>>&g
Am Fri, Dec 20, 2024 at 09:06:45PM +0900 schrieb Maxim Cournoyer:
> I think the Guix binary release can be built from aarch64; we've never
> had true armhf offload machines, as far as I know.
We did, and it still exists! Guix Foundation owns a Novena board that
was donated to us b
Greg Hogan writes:
> On Wed, Dec 18, 2024 at 12:43 PM Suhail Singh
> wrote:
>>
>> Suhail Singh writes:
>>
>> > The issue, as I see it, is the time commitment required from the
>> > release-team.
>>
>> Correction, the issues (IMO) are (in n
Hi,
Greg Hogan writes:
> On Wed, Dec 18, 2024 at 11:49 AM Ludovic Courtès wrote:
>> As has been discussed multiple times at the Guix Days and on this list
>> (I think?), I believe what we need is a release team with rotating
>> duties. That is, a bunch of 3–5 people com
Hi Greg,
Greg Hogan writes:
> On Wed, Dec 18, 2024 at 12:43 PM Suhail Singh
> wrote:
>>
>> Suhail Singh writes:
>>
>> > The issue, as I see it, is the time commitment required from the
>> > release-team.
>>
>> Correction, the issues
On Wed, Dec 18, 2024 at 11:49 AM Ludovic Courtès wrote:
> As has been discussed multiple times at the Guix Days and on this list
> (I think?), I believe what we need is a release team with rotating
> duties. That is, a bunch of 3–5 people commit to doing the work leading
> to 1.5.0
On Wed, Dec 18, 2024 at 12:43 PM Suhail Singh wrote:
>
> Suhail Singh writes:
>
> > The issue, as I see it, is the time commitment required from the
> > release-team.
>
> Correction, the issues (IMO) are (in no particular order):
> 1. the timespan (several weeks)
I think it is
>> better to ignore branches for now and focus on coming to an agreement
>> about more frequent releases, lest this discussion, too, ends up
>> reiterating "stable" branches and the finer points of release
>> maintenance.
>>
>> > - major s
Suhail Singh writes:
> The issue, as I see it, is the time commitment required from the
> release-team.
Correction, the issues (IMO) are (in no particular order):
1. the timespan (several weeks)
2. uncertainty around total effort
3. amount of manual effort involved
It's unclear w
Ludovic Courtès writes:
> I believe what we need is a release team with rotating duties. That
> is, a bunch of 3–5 people commit to doing the work leading to 1.5.0;
> then a new team (possibly with overlap) takes over for the next
> version, and so on.
The issue, as I see it,
of the actual guix package is for the daemon
>>> >> and the installer, I think we could tag a minor release just about every
>>> >> time we bump the guix package.
>>>
>>> That's a sensible approach. How should the discussion proceed further?
Maxim Cournoyer writes:
> If we can agree that producing a release with lowered expectations is
> better than producing none, I don't mind to get the ball going.
I think it would be helpful to consider our approach for the upcoming
release distinctly from what we choose to do for
"pelzflorian (Florian Pelz)" writes:
> Ricardo Wurmus writes:
>> Efraim Flashner writes:
>>> Lets make releases boring :)
>>
>> I'm a very boring person, so this deeply resonates with me.
>>
>> No matter if people agree with this or
>> and the installer, I think we could tag a minor release just about every
>> >> time we bump the guix package.
>>
>> That's a sensible approach. How should the discussion proceed further?
>> Do we have a proxy to determine whether everyone who needs to b
Ricardo Wurmus writes:
> Efraim Flashner writes:
>> Lets make releases boring :)
>
> I'm a very boring person, so this deeply resonates with me.
>
> No matter if people agree with this or not, I think we should get a new
> release out very soon. Do you know
On Sun, Dec 15, 2024 at 03:21:44PM -0500, Suhail Singh wrote:
> Ricardo Wurmus writes:
>
> > Efraim Flashner writes:
> >
> >> Since, IMO, the major uses of the actual guix package is for the daemon
> >> and the installer, I think we could tag a minor releas
Ricardo Wurmus writes:
>> What does making a release entail? Is this documented somewhere?
>
> It is documented:
>
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org
Thank you. Should this be linked from the Guix manual? Or is the
omission intentional?
--
Suhail
Suhail Singh writes:
> Ricardo Wurmus writes:
>
>> I've only ever signed off on one release (0.13.0?) and I'd be happy to
>> help get another one out of the door.
>
> What does making a release entail? Is this documented somewhere?
It is documented:
http
Ricardo Wurmus writes:
> Efraim Flashner writes:
>
>> Since, IMO, the major uses of the actual guix package is for the daemon
>> and the installer, I think we could tag a minor release just about every
>> time we bump the guix package.
That's a sensible approac
Efraim Flashner writes:
> Since, IMO, the major uses of the actual guix package is for the daemon
> and the installer, I think we could tag a minor release just about every
> time we bump the guix package.
>
> Lets make releases boring :)
I'm a very boring person, so this d
> Changing the branching model is very difficult to do. I think it is
> better to ignore branches for now and focus on coming to an agreement
> about more frequent releases, lest this discussion, too, ends up
> reiterating "stable" branches and the finer points of release
>
> Our releases should mean something.
one thing i haven't seen mentioned:
AFAIU, not any version of guix can pull and build another guix version. i.e.
when the guix command gets a new feature that is then used in the code that
pulls and builds itself, then we have a bootstrap/staging problem no
ng against. But I have a doubt.
In "22.8.3 Version Numbers", we state that "Occasionally, we package
snapshots of upstream’s version control system (VCS) instead of formal
releases. This should remain exceptional, because it is up to upstream
developers to clarify what the stab
Ricardo Wurmus writes:
> This has been discussed in the past and it is far from trivial.
> Consider that glibc needs Python at build time and the Linux kernel may
> need Rust. Consider also that it is easy to introduce a package from
> the outer ring to the inner ring through transitive dependen
ote:
Our releases should mean something.
What do they mean, please?
This is actually related to the topic I wanted to bring up before we really get
lost in the details of release building and so on.
I've always thought about Guix as a rolling distribution, where our "releases" a
is split into more than one channel doesn't obviate the
need to define and agree upon a release model (which is what this thread
is about): either the current state where installer snapshots come after
several months, or some alternate future state the community sees value
in.
--
Suhail
Ricardo Wurmus writes:
>> Let's say we have two channels in the future: $guix-slim and
>> $guix-extras. Wouldn't it be sufficient for $guix-extras to depend on
>> $guix-slim ? If not, could you please elaborate?
>
> You have multiplied the release proble
Suhail Singh writes:
> Tomas Volf <~@wolfsden.cz> writes:
>
>> I would like to point out that there is more work involved than just
>> splitting it into separate channels and adding those into
>> %default-channels.
>
> Could you please elaborate? Or were these the two points you noted
> below?
n
> $guix-slim ? If not, could you please elaborate?
You have multiplied the release problem by two.
guix-slim and guix-extras would both need to be versioned somehow, so
that whatever packages and Guix library infrastructure guix-extras needs
are in fact provided by the version of guix-slim.
Simon Josefsson via "Development of GNU Guix and the GNU System distribution."
writes:
> How much of the guix git repository content can you remove and still
> have a working OS? In other words, can we strip away almost all of the
> packages and still have a minimal bootable system? If we mini
y related to the topic I wanted to bring up before we really get
lost in the details of release building and so on.
I've always thought about Guix as a rolling distribution, where our "releases"
are essentially installer "snapshots." In other words, the installer has
Hi Ricardo,
On Fri, Dec 13 2024, Ricardo Wurmus wrote:
> Our releases should mean something.
What do they mean, please?
Kind regards
Felix
P.S. No flames, please. It's an innocent question.
Ricardo Wurmus writes:
> Suhail Singh writes:
>
>> Assuming my understanding above is correct, wouldn't you agree that
>> (even) for those individuals what's most important is that there is a
>> _stable_ and _not-very-outdated_ release available? My (and I bel
Tomas Volf <~@wolfsden.cz> writes:
> I would like to point out that there is more work involved than just
> splitting it into separate channels and adding those into
> %default-channels.
Could you please elaborate? Or were these the two points you noted
below?
> While multiple channels do work
Suhail Singh writes:
> Assuming my understanding above is correct, wouldn't you agree that
> (even) for those individuals what's most important is that there is a
> _stable_ and _not-very-outdated_ release available? My (and I believe
> Greg's) contention is that fol
n't understand the
> instructions to perform a "guix pull". Further, the number of such
> individuals is greater than zero, and you are proposing that we consider
> their needs when determining the release process for Guix.
Correct. Except the number of such individuals is hug
Suhail Singh writes:
> Simon Josefsson via "Development of GNU Guix and the GNU System
> distribution." writes:
>
>> can we strip away almost all of the packages and still have a minimal
>> bootable system? If we minimize that set of really-core packages,
>> maybe there can be one team that wor
Simon Josefsson via "Development of GNU Guix and the GNU System
distribution." writes:
> can we strip away almost all of the packages and still have a minimal
> bootable system? If we minimize that set of really-core packages,
> maybe there can be one team that works on this minimal bootable OS
duals who would be able to follow the instructions
to install Guix. However, these individuals wouldn't understand the
instructions to perform a "guix pull". Further, the number of such
individuals is greater than zero, and you are proposing that we consider
their needs when determi
>ven. 13 déc. 2024 at 10:52, Suhail Singh wrote:
> Greg Hogan writes:
>
>> We only need a release team and a documented release process. Releases
>> should be scheduled rather than depending on other teams. What benefit
>> is there to the Guix user when glibc or
How much of the guix git repository content can you remove and still
have a working OS? In other words, can we strip away almost all of the
packages and still have a minimal bootable system? If we minimize that
set of really-core packages, maybe there can be one team that works on
this minimal bo
Suhail Singh writes:
> If the goal is to increase the frequency of releases while maintaining
> quality, the only consideration that the teams-branch ought to make is
> to ensure that the commit in question (corresponding to th
Greg Hogan writes:
> We only need a release team and a documented release process. Releases
> should be scheduled rather than depending on other teams. What benefit
> is there to the Guix user when glibc or the default gcc are updated?
> You're only a "guix pull"
On Fri, Dec 13, 2024 at 8:02 AM Suhail Singh wrote:
>
> Ricardo Wurmus writes:
>
> > Releases are made a short time after the core team branch is merged.
> > This would give us a new release whenever e.g. the default GCC and
> > glibc is bumped up. We could aim for
Ricardo Wurmus writes:
> Releases are made a short time after the core team branch is merged.
> This would give us a new release whenever e.g. the default GCC and
> glibc is bumped up. We could aim for a release two months after the
> merge to allow for minor fixes after the mer
ow and focus on coming to an agreement
about more frequent releases, lest this discussion, too, ends up
reiterating "stable" branches and the finer points of release
maintenance.
> - major should follow core merges to devel
> - minor should follow non-core teams merges
I think this i
Hi Guix,
Let me spin off last year thread on releases (flavored by an external to
the project point of view), with the goal to relaunch the debate on
releases.
Disclaimer: the rolling release model is great and more than enough for
me, and teams constitute an mportant step forward.
Disclaimer
On Tue, 10 Sep 2024 18:21:17 -0400
Greg Hogan wrote:
> With Guix embracing the chaos of rolling releases, and a presumption
> that users will `guix pull` soon after installation, I count only
> three motivations to tag a new release: 1) replacing an old release
> with an outdated Gu
>
> That seems like a lengthy time to roll some release artifacts. Is the
> remaining effort to fix failing builds?
Fixing failing builds, but more importantly fixing issues with the
installer, which receives little attention during the rest of the time.
[...]
> Whether the remainder of t
Hi Greg, Ludo',
I think 5 months are a long but not unbelieveable amount of time, especially if
the team has to be onboarded in that time frame as well.
I work for my dayjob as Release Engineer at a company that makes another Linux
distribution, so I happen to have an idea of some o
On Fri, Sep 6, 2024 at 5:32 AM Ludovic Courtès wrote:
>
> Hi Greg,
>
> Greg Hogan skribis:
>
> > With the recent core-updates merge, and as the master branch
> > stabilizes, is there a plan or desire for a 1.5.0 release?
>
> Desire, definitely; plan? we have
Hi Greg,
Greg Hogan skribis:
> With the recent core-updates merge, and as the master branch
> stabilizes, is there a plan or desire for a 1.5.0 release?
Desire, definitely; plan? we have to come up with one.
I think there should be a team of ~4 volunteers who can commit to focus
on
Hi Guix,
With the recent core-updates merge, and as the master branch
stabilizes, is there a plan or desire for a 1.5.0 release?
It has been 20 months since the 1.4.0 release, which is already more
than the previously longest interval (18 months for v1.4.0). 2023 was
the first year without a
Am Tue, May 14, 2024 at 11:41:26AM +0200 schrieb Ludovic Courtès:
> As discussed at the 2023 Guix Days (!), we could follow a model similar
> to that of NixOS: form a release team (~4 people) dedicated to keeping
> track of issues in particular wrt. the installer, and committed to
>
Christina O'Donnell writes:
> On 08/05/2024 14:01, Christopher Baines wrote:
>> I think it would be nice to have a new release, and indeed release more
>> often, I think the way to get there is for less things to be broken
>> between releases, such that releasing tak
Hi,
On 08/05/2024 14:01, Christopher Baines wrote:
I think it would be nice to have a new release, and indeed release more
often, I think the way to get there is for less things to be broken
between releases, such that releasing takes less effort in terms of
testing and fixing things.
To give
could follow a model similar
to that of NixOS: form a release team (~4 people) dedicated to keeping
track of issues in particular wrt. the installer, and committed to
publishing a release within 4–6 months. (I think several people actually
volunteered back in Feb. 2023. :-))
After that, another team, po
> bug report above.
>
> Well, the bugs appear because the user is upgrading guix-daemon. ;-)
>
> In both cases (#70659 and #70726), it comes from a fresh install (latest
> release v1.4.0) and then the first ’guix pull’ aiming to upgrade all
> leads to that reported error.
Hi,
I am late to the party…
On mer., 10 avril 2024 at 15:57, Ludovic Courtès wrote:
>> That has happened to me too.
>> Why not use Git directly always?
>
> Because it create{s,d} a bootstrapping issue. The
> “builtin:git-download” method was added only recently to guix-daemon and
> cannot be
Re,
On lun., 06 mai 2024 at 13:12, Simon Tournier wrote:
> Although these days I do not have much free time, let make a new release
> as soon as possible. WDYT?
>
> Who’s in?
Well, the patch review sessions could be helpful. Maybe we could run
some online hackathons. IMHO, havin
ser is upgrading guix-daemon. ;-)
In both cases (#70659 and #70726), it comes from a fresh install (latest
release v1.4.0) and then the first ’guix pull’ aiming to upgrade all
leads to that reported error.
Therefore, I strongly advise upgrading latest Guix release. ;-)
Although these days I
Hi,
Skyler Ferris skribis:
> In short, I'm not sure that we actually get any value from checking the
> PGP signature for most projects. Either HTTPS is good enough or the
> attacker won. 99% of the time HTTPS is good enough (though it is notable
> that the remaining 1% has a disproportionate
34s1mn5p@xelera.eu/)
>>>
>>> ...and if needed read that message again to understand the context,
>>> please.
>>>
>> I assume that this was an indirect response to the email I sent
>> previously where I discussed the problems with PGP signatures on re
ystem of rules for attackers to manipulate. On the other hand, if we
assume people aren't doing the things they need to then no amount of
technical support will give us a secure system. How much is reasonable
to expect of people? From my extremely biased perspective, it's
difficult to s
o understand the context,
> please.
>
>
I assume that this was an indirect response to the email I sent
previously where I discussed the problems with PGP signatures on release
files. I believe that this was in scope because of the discussion about
whether to use VCS checkouts which l
n to understand the context,
>> please.
>>
> I assume that this was an indirect response to the email I sent
> previously where I discussed the problems with PGP signatures on release
> files.
No, believe me! I'm sorry I gave you this impression. :-)
> I believe that
Hi Attila,
sorry for the delay in my reply,
I'm asking myself if this (sub)thread should be "condensed" in a
dedicated RFC (are RFCs official workflows in Guix, now?); if so, I
volunteer to file such an RFC in the next weeks.
Attila Lendvai writes:
>> Are there other issues (different from the
m should really do: have a reasonable level of
trust that the origin is really the upstream one.
But here we are /brainstormig/ about the very issue that led to the
backdoor injection, and that issue is how to avoid "backdoor injections
via build subversion exploiting semi-binary seeds in rel
lie in addressing bootstrapping issues with core
> packages: glibc, GCC, Binutils, Coreutils, etc. I’m not sure how to do
> that but…
does it have to be an "all of nothing" choiche? I mean "continue using
release tarballs" vs "use git" for "all"?
If usi
Hi!
Andreas Enge skribis:
> Am Wed, Apr 10, 2024 at 03:57:20PM +0200 schrieb Ludovic Courtès:
>> I think we should gradually move to building everything from
>> source—i.e., fetching code from VCS and adding Autoconf & co. as inputs.
>
> the big drawback of this approach is that we would lose ma
> > I think we should gradually move to building everything from
> > source—i.e., fetching code from VCS and adding Autoconf & co. as inputs.
>
>
> the big drawback of this approach is that we would lose maintainers'
> signatures, right?
it's possible to sign git commits and (annotated) tags, t
Hi,
and everybody is reading.
This is a steep claim! I agree that nobody reads generated files in
a release tarball, but I am not sure how many other files are actually
read.
Yea, it is. I'd also love to know how effective is the reading in a
release tarball vs a VCS repo. Quality o
inguish
the "original" from its clones in a VCS. With the signature by the
known (this may also be a wrong assumption, admittedly) maintainer
there is at least some form of assurance of origin.
> and everybody is reading.
This is a steep claim! I agree that nobody reads generated files in
a r
h is that we would lose maintainers'
signatures, right?
Would the suggestion to use signed tarballs, but to autoreconf the
generated files, not be a better compromise between trusting and
distrusting upstream maintainers?
Andreas
Probably not, because the release tarballs might code th
Hello,
Am Wed, Apr 10, 2024 at 03:57:20PM +0200 schrieb Ludovic Courtès:
> I think we should gradually move to building everything from
> source—i.e., fetching code from VCS and adding Autoconf & co. as inputs.
the big drawback of this approach is that we would lose maintainers'
signatures, right
the bootstrapping repos, git-archive them
> ourselves and host them properly signed. At least, we could challenge
> them using git (similar to what we do with the substitutes), which we
> cannot do right now with the release tarballs against the actual code
> of the repository.
I
On Thu, 04 Apr 2024 12:34:42 +0200
Giovanni Biscuolo wrote:
> Hello everybody,
>
> I know for sure that Guix maintainers and developers are working on
> this, I'm just asking to find some time to inform and possibly discuss
> with users (also in guix-devel) on what measures GNU Guix - the
> soft
building from git? which, i think,
would even take less effort.
> > but these generated man files are part of the release tarball, so
> > cross compilation works fine using the tarball.
>
>
> AFAIU in this case there is an easy alternative: distribute the
> (genera
numerous, especially among the core GNU components.
OK, thank you for the confirmation.
[...]
>> ...or is it better to completely avoid release tarballs as our sources
>> uris?
>
> yes, and this^ would guarantee the previous point, but it's not always
> trivial.
>
gure
scripts are expected to be near incomprehensible. They contain no
comments, are filled to the brim with portable (lowest common
denominator) shell magic, and contain bizarrely named variables.
Not using generated output is a good idea anyway and removes the
requirement to trust that the release tarb
them. And we'll be forced to use git, too, or at least
clone the bootstrapping repos, git-archive them ourselves and host them
properly signed. At least, we could challenge them using git (similar to
what we do with the substitutes), which we cannot do right now with the
release tarballs a
undreds of thousand of lines of configure
> scripts and other (auto)generated files bundled in release tarballs
> "pragmatically impossible" to be peer reviewed?
yes.
> Can we consider that artifacts as sort-of-binary and "force" our
> build-systems to r
was
> acquired from. if the hash matches the one in the package definition,
> then it's the same archive that the guix packager has seen while
> packaging.
Ehrm, you are right, mine was a stupid question :-)
We *are* already verifying that tarballs had not been tampered
Hello,
a couple of additional (IMO) useful resources...
Giovanni Biscuolo writes:
[...]
> Let me highlight this: «It is pragmatically impossible [...] to peer
> review a tarball prepared in this manner.»
>
> There is no doubt that the release tarball is a very weak "trusted
&
1 - 100 of 868 matches
Mail list logo
