<ris>
i think it needs to be updated, see my last comment
<ris>
5.4.1 has the fix
<gchristensen>
yeah, but do you want to build on top of that PR?
<gchristensen>
like I'll merge that ,you open a new bump PR
<gchristensen>
or?
<ris>
oh... could yeah
<gchristensen>
up to you
<ris>
yeah good idea
<gchristensen>
which? :)
<ris>
merge it
<ris>
it will give least confusing history
justanotheruser has quit [Ping timeout: 244 seconds]
<ris>
gchristensen: turns out the fixed versions haven't actually been released yet - but the patches for the fixes are in the repo - e.g. the last 7 commits on https://libvirt.org/git/?p=libvirt.git;a=shortlog;h=refs/heads/v4.10-maint are all CVE fixes... rather than add each patch separately it feels more sensible to just point at that top commit ...?
<gchristensen>
I think nicer to start with the release and apply patches from there, but not sure that is a rule
<ris>
ok, we're getting 7 patches then...
<ris>
have people ever considered adding a version postfix for patched packages (like debian do -debXuY) to allow people to have some reassurance they're not running vulnerable versions?
<ris>
i imagine people using naive vulnerability scanners get all kinds of warnings for things we've patched because it only goes on versions
<gchristensen>
yeah that is an interesting question
<samueldr>
+1 for the idea
<qyliss>
How would that help?
<qyliss>
How do you know -nixpkgs2 has the fix but -nixpkgs1 doesn't?
<qyliss>
(Not necessarily against the idea, just trying to understand)
<samueldr>
it would help knowing it _changed_
<samueldr>
in advisories we could say "fixed in hello-1.0.2~nixpkgs+2" or whatever scheme
<qyliss>
Do we even issue any sort of advisory currently?
<samueldr>
work for the future
<samueldr>
I think it's not a bad idea to prepare for this, at least for the major publicised issues
<qyliss>
yeah...
<qyliss>
makes sense I guess
<pie_>
is anyone taking notes
<qyliss>
{`-`} is :P
<pie_>
;D
<ris>
samueldr: in my mind, at least you know it's not the same
<qyliss>
assuming you memorised your old versions?
<ris>
it gives vuln scanning tools at least the _ability_ to have an idea from the version numbers
<qyliss>
also, with Debian, there's a clear meaning to a revision -- it's a build of a package
<qyliss>
suppose the vulnerability exists in some other build-time dependency
<ris>
and it possibly gives "us" the ability to say at some point in the future "it's fixed in version x"
<ris>
i agree that the analogy isn't 1:1 with debian/nix
<ris>
because in nix the packages are far more ... flexible
<ris>
fluid
<samueldr>
it's not only a security thing
<samueldr>
my use case in the past would have been grub
<qyliss>
so then we might get into a situation where we have to bump a huge number of packages to communicate something, even though there's otherwise no need
<samueldr>
grub direly needs a bunch of patches to be actually working right
<samueldr>
does debian change the verison of software dependent on something having bumped?
<samueldr>
(I don't know)
<qyliss>
I know we did in Homebrew
<qyliss>
because that was the only way to trigger a rebuild
<samueldr>
hm
<ris>
hmm yeah it's interesting - if you make a fix that only affects one platform, nix will only cause rebuilds on that platform ... unless you also bump the sub-version number, in which case it's rebuilds all round
<ris>
whether they have any effect or not
<samueldr>
(uselessly) rebuilds all around
<samueldr>
:)
<qyliss>
I think I'm soft-opposed to this idea as things stand
<qyliss>
But something that actually communicates "includes patches for CVE-XXXX-XXXXX" would be cool
<ris>
yeah ... idunno, some meta attribute
<qyliss>
I think this might have been discussed before?
<qyliss>
But maybe the other way around
<qyliss>
As in, known vulnerabilities
<qyliss>
which is of course doomed to failure
<ris>
ah
<samueldr>
meta.vulnerabilities = [ "*" ];
<ris>
i suppose there could be some magic file in nix-support
<ris>
but wait, then you can't tell whether a package has a fix until you build it
<ekleog>
actually having some ~nixpkgs* to show that we applied patches (even ~nixpkgs0 for when we apply a patch even if the patch was already there before) would make sense to me: it'd make it easier to see which packages are running “vanilla”
<samueldr>
ekleog: yeah, my point previously "not only a security thing" :)
<ekleog>
yup, just wanted to make that explicit :)
<qyliss>
It introduces weird semantics with patches vs substituteInPlace though
<qyliss>
does one count as a patch and the other doesn't?
<samueldr>
right, was thinking about that
<qyliss>
I think it should be assumed that no packages are "vanilla"
<ris>
but i can see how it could cause weirdness for many of our packages that are more ... polymorphic/obtuse/etc
<ekleog>
both would count as (which is also why ~nixpkgs${builtins.len self.patches} can't work)
<samueldr>
I think the difference could be "is it a fixup for /nix/* intricacies or is it a feature/bug fix?"
<samueldr>
where imo fixing missing support for PREFIX is a bugfix :)
<qyliss>
mmm
<ekleog>
to me ~nixpkgs0 is “all the fixups for /nix/*”, and ~nixpkgsI is for more stuff
<qyliss>
I don't like how shakey this is
<qyliss>
Also, what does it mean to have nixpkgs2 vs nixpkgs3?
<qyliss>
What does that tell you?
<samueldr>
(thinking) version numbers already are shakey
<ekleog>
it means some patch changed
<qyliss>
What if the fixups for /nix change?
<qyliss>
samueldr: agree, but at least they're static and come from upstream
<samueldr>
yeah
<ekleog>
well, they shouldn't need to? if they do then it's likely a bugfix and it gets a ++
<ekleog>
not 100% sure it'd be great (eg. it'd more or less break nix-diff in its current state, I think), but it'd be some piece of additional information
<ekleog>
(and upstream would more easily know it's a nix-patched thing if it receives a ~nix3 version number)
<ekleog>
now… well, in nix in some way all the version numbers are fixed by nixpkgs hash, so…
<ris>
gchristensen: a good reason for doing them as separate patches after all - turns out one of the patches breaks the darwin build so at least this way i can conditionally disable it
<qyliss>
ekleog: for upstream to be informed of such, we'd have to patch --version output and stuff
<qyliss>
/please/ let's not become debian!
<ekleog>
qyliss: I was thinking of showing the full /nix/store path, but it's true it reduces interest