gchristensen changed the topic of #nixos-security to: Vulnerability Roundup Issues: https://github.com/NixOS/nixpkgs/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+Vulnerability+roundup + https://broken.sh
justanotheruser has joined #nixos-security
justanotheruser has quit [Ping timeout: 258 seconds]
justanotheruser has joined #nixos-security
justanotheruser has quit [Ping timeout: 245 seconds]
justanotheruser has joined #nixos-security
erictapen has joined #nixos-security
c4rc4s has quit [Remote host closed the connection]
c4rc4s has joined #nixos-security
pietranera has joined #nixos-security
erictapen has quit [Ping timeout: 244 seconds]
hmpffff has joined #nixos-security
justan0theruser has joined #nixos-security
justanotheruser has quit [Ping timeout: 258 seconds]
erictapen has joined #nixos-security
hmpffff has quit [Quit: Bye…]
hmpffff has joined #nixos-security
<pie_> I wonder if we could pre-distribute encrypted security fixes
<pie_> *escrowed
<pie_> ok maybe thats pointless though
<pie_> if you can distribute the encryption key there isnt really a reason you couldnt distribute the fix
<gchristensen> no
<gchristensen> one of the rules is there must be no side-channel information leaking the fact that there even is a vulnerability
<pie_> fair enough, for the sake of argument though, if its properly encrypted that means yuo dont know anything about the target?
<gchristensen> the target doesn't matter
<gchristensen> for example: hydra.nixos.org suddenly losing a lot of capacity to take it over to a different secret hydra would be an inapropriate information leakage
<xorAxAx> where does that requirement come from?
<gchristensen> the linux-distros list
<xorAxAx> ah, and its valid before coordinated release?
<xorAxAx> s/valid/in effect/
<gchristensen> right
<xorAxAx> well, you would need a second hydra instance then - which runs on a separate machine
<xorAxAx> in debian, the security team is separate from many things
<gchristensen> exactly
<pie_> ok so the existence of _any_ vulnerability
<pie_> that seems needlessly restrictive?
<gchristensen> of vulns shared on linux-distros, yes
erictapen has quit [Ping timeout: 268 seconds]
pietranera has quit [Quit: Leaving.]
Henson has joined #nixos-security
<Henson> andi-: are you around?
<Henson> gchristensen: are you around?
<aanderse> Henson: whats up?
<aanderse> security issue?
<aanderse> :)
<Henson> Yeah, just confirming that with the openssh pull request I should just make the changes to the master branch and do a pull request on the master branch, and not make a separate topic branch (which is something github's pull request info documents suggest)
<qyliss> You mean your fork's master branch?
<qyliss> I'd recommend against it, because you can't use that branch for anything else without affecting your pull request
<Henson> Yes
<qyliss> Strongly recommend just creating a different branch.
<Henson> Ok, so separate topic branch is the way to go, then request merging the topic branch into nixos master?
<qyliss> Yep.
<qyliss> Or staging, depending on what's appropriate.
<Henson> Ok, that makes sense
<Henson> Well, I've never done this before, so whatever is the most correct way to do this. Should I request a pull into staging?
<qyliss> Staging is for changes that require lots of rebuilds.
<qyliss> What are you changing?
<Henson> Fixing two CVE vulnerabilities in the openssh package.
<qyliss> Put that to staging
<Henson> Ok
<qyliss> Lots of things depend on OpenSSH and would have to be rebuilt.
<qyliss> So it can't go straight to master.
<Henson> Brb, need to hop off WiFi and onto mobile
Henson has quit [Remote host closed the connection]
<aanderse> you're awesome Henson!
Henson has joined #nixos-security
<Henson> Ok, I'm back
<qyliss> Henson: while you were away you missed:
<qyliss> <aanderse> you're awesome Henson!
<aanderse> ^_^
erictapen has joined #nixos-security
<qyliss> Henson: the one other thing I was going to suggest if you're new to this is to create your branch from staging, rather than master. Otherwise it's easy to end up sending a PR for all of master to be merged into staging, as well as your changes.
justan0theruser is now known as justanotheruser
<Henson> Ok, so create a topic branch from staging and request it be merged into staging.
erictapen has quit [Ping timeout: 246 seconds]
<qyliss> Yeah
erictapen has joined #nixos-security
<Henson> Ok, thanks for the help!
<qyliss> Post the PR when it's done and I'll have a look if I'm still awake
<Henson> I probably won't get around to it until several hours from now, if at all today, so don't wait up :-)
<Henson> And what exactly do you mean by "post the PR"?
<qyliss> Like, once you've made a pull request, post its URL in this channel and mention my IRC nick so I'm notified of it.
erictapen has quit [Ping timeout: 244 seconds]
<Henson> Ok
<Henson> It looks like some people use their real names in git commits, and some use aliases. Any best practice recommendations on that one?
<qyliss> If you're comfortable using your real name, do.
<qyliss> Although be aware that you can never change your mind, because we can't change the git history.
<Henson> Oh, also after a huge delay, thanks aanderse :-)
hmpffff has quit [Quit: nchrrrr…]