Comments (10)
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.
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.
Related Issues (20)
- 0.1.208 crashes windows 11 on loading viostor HOT 9
- RedHad signature in https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso is expired HOT 2
- Balloon driver installation failure on Windows Server 2008 R2 HOT 11
- virtio-win RPM | Guest agent reported by virt-manager as non available HOT 3
- Program virtio-win-guest-tools.exe fails to install into the guest HOT 15
- virtio-win-0.1.217-1 broken storage driver for windows 2012R2 HOT 2
- git commit hash related with certain version of virtio-win.iso HOT 1
- 0.1.217 Windows 11 MSI/EXE Failed Install HOT 5
- virtio-win-0.1.217 - issue NetKVM Windows 2k12R2 driver HOT 7
- Win SRV 2019 - Error 0x80070643 HOT 10
- please offer individual binary drivers downloads
- ssl certificate expired for fedorapeople.org HOT 3
- Win2k12 with VirtIO Screen fails to install RH VirtIO GPU DOD controller HOT 5
- Download links broken HOT 1
- Installer placement on the ISO filesystem can lead to user confusion HOT 9
- Windows VM loses static IP address after upgrading virtio-win drivers HOT 6
- Graphics makes VM lag out. HOT 1
- Program virtio-win-guest-tools.exe fails to install into the guest HOT 12
- Feature request: MSI file for ARM64 HOT 1
- [Question] Options for CMD install (virtio-win-guest-tools.exe) HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from virtio-win-pkg-scripts.