gpg sign RPMs about virtio-win-pkg-scripts HOT 10 OPEN

Just to make this clear. What this means for users is that if they have ever installed the virtio-win package per the instructions, they will be vulnerable to being rooted by a man in the middle attack every time they do a yum upgrade even if they have uninstalled virtio-win, the only fix is to disable the repo itself.

from virtio-win-pkg-scripts.

This is now CVE-2020-29665

from virtio-win-pkg-scripts.

@crobinso It looks like a really easy improvement would be to change the repo file to use https. PR #38

from virtio-win-pkg-scripts.

DNF maintainers say that DNF does not check https certs, and will even allow redirects to non-http sites: see https://bugzilla.redhat.com/show_bug.cgi

from virtio-win-pkg-scripts.

That link isn't complete — what's the bug number you're referring to?

DNF in Fedora does check https signatures — sslverify is on by default, and therefore "If the client can not be authenticated, connecting fails and the repository is not used any further."

However, I don't think in pins the certs or in any way validates beyond "is this a valid cert linked to our chain of trust", so it isn't sufficient. It's just an easy improvement that can be implemented quickly.

My suggestion is that virtio-win move to using Copr to generate the repo, because that includes a process for GPG signing. Cole mentioned that one problem with that is that Copr doesn't retain old versions, but that could be solved by a script copying to fedorapeople without deleting old copies there.

from virtio-win-pkg-scripts.

Oh woops, sorry, copy&paste snafu: https://bugzilla.redhat.com/show_bug.cgi?id=1878595

Yeah, I think if you get the ssl cert validated to the installed ssl chain of trust then that would be a
find fine interim fix, at least it's a package from a fedora site, which is what's expected!

from virtio-win-pkg-scripts.

@vrozenfe I see virtio-win 190 is published on fedorapeople.org but the virtio-win.spec in the repo is still pointing to 189, can you push those spec changes?

I'm experimenting with adding a copr repo, but there's some friction. Having to add a different chroot for every possible consumer (all fedora versions, centos, rhel, etc) is pretty wasteful, and needs to be bumped forward as new chroots pop up. Compared to the old repo which was just 'take the damn RPM' because the content is entirely independent of the host it is being installed on.

Our spec file conditionals are also tied to the distro we are building on, which is arbitrary: there's a RHEL set of defaults and a non-RHEL/Fedora set of defaults and the host we build on isn't really the distinctive piece. These repos should always be shipping the non-RHEL defaults. It will take some work to change the wiring for that.

I'm kinda thinking we just kill the yum repo entirely but keep building and publishing RPMs. Maybe add the rpm and srpm the stable/latest symlink dirs in the direct-downloads folder and call it a day. https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/

from virtio-win-pkg-scripts.

@crobinso
7a97bab

Speaking about possible changes in RHEL/Fedora spec files, I have to say that after Feb 22nd the entire cross-signing procedure that we use for signing upstream virtio-win drivers will be deprecated https://docs.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates
So, expect some unpleasant changes, related to Fedora virtio-win project, happen in the near future.

from virtio-win-pkg-scripts.

Thanks @vrozenfe

I added stable links to the RPMs now, only for the current 'stable' and 'latest' builds. See these URLs:

https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win.noarch.rpm
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win.src.rpm
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.noarch.rpm
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.src.rpm

They will resolve to a full versioned RPM download. The directories also have full versioned RPM filenames in them too.

As for the yum repo, I'm thinking if we rename the package folders, like stable -> insecure-stable, current users will have a busted repo, but they can fix it with a sed call if they are desperate. That will let us know in the short term if anyone is dependent on the repo, like in CI somewhere. Depending on the feedback we get we can decide whether to spend the time wiring up a copr repo or not.

I will also work on transferring the fedora docs over to this repo, more easily under our control (like the old fedora wiki page was)

from virtio-win-pkg-scripts.

I updated the README on this repo to provide a slimmed down version of the Fedora docs. I filed a request to kill the Fedora docs. Once that's done, we can figure out a strategy for killing or changing the virtio-win repo without inconsistent documentation floating around

from virtio-win-pkg-scripts.