Posted by Jeffrey Walton on Aug 19
https://bugzilla.redhat.com/show_bug.cgi?id=1873876
Jeff
Posted by Jeffrey Walton on Aug 19
https://bugzilla.redhat.com/show_bug.cgi?id=1873876
Jeff
Posted by Michael Lazin on Aug 19
I would test it using sha256 instead of md5 before you jump to conclusions
but dnf doesn’t use https by default and you need to jump through hoops to
get it working. I would say if you are a fedora user open a feature
request for https for dnf with the fedora team if you can repeat this with
sha256.
Peace,
Michael
Posted by Matthew Fernandez on Aug 19
If the VM had no access to the internet even a retry would fail, no?
If an attempted update based on a delta-rpm fails, dnf falls back to
downloading a full rpm and using this instead.
Posted by Adrean Boyadzhiev on Aug 19
Probably a completely different root cause, but I have noticed similar
behavior with a Debian-based distribution during `# apt upgrade` and
when there are many packages for update and the internet connection is
not so good. I haven’t investigated, but my assumptions were either Race
Conditions within verification logic or some logic related to the timestamp.
To my knowledge `md5` should be ok for calculating hash sums, many
prefer it…
Multiple vulnerabilities have been discovered in Junos OS, which. when chained together. could allow for remote code execution. Junos OS is an operating system that runs across all Juniper routing, switching, and security infrastructure. Successful chain exploitation of these vulnerabilities could allow for remote code execution in the context of the affected service account. Depending on the privileges associated with the service account an attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Service accounts that are configured to have fewer user rights on the system could be less impacted than those who operate with administrative user rights.
DOM-based XSS in src/muya/lib/contentState/pasteCtrl.js in MarkText 0.17.1 and before on Windows, Linux and macOS allows arbitrary JavaScript code to run in the context of MarkText main window. This vulnerability can be exploited if a user copies text from a malicious webpage and paste it into MarkText.
DOM-based XSS in updater/update.html in Typora before 1.6.7 on Windows and Linux allows a crafted markdown file to run arbitrary JavaScript code in the context of Typora main window via loading typora://app/typemark/updater/update.html in <embed> tag. This vulnerability can be exploited if a user opens a malicious markdown file in Typora, or copies text from a malicious webpage and paste it into Typora.
Improper path handling in Typora before 1.6.7 on Windows and Linux allows a crafted webpage to access local files and exfiltrate them to remote web servers via “typora://app/<absolute-path>”.
This vulnerability can be exploited if a user opens a malicious markdown file in Typora, or copies text from a malicious webpage and paste it into Typora.
Improper path handling in Obsidian desktop before 1.2.8 on Windows, Linux and macOS allows a crafted webpage to access local files and exfiltrate them to remote web servers via “app://local/<absolute-path>”. This vulnerability can be exploited if a user opens a malicious markdown file in Obsidian, or copies text from a malicious webpage and paste it into Obsidian.
clamav-1.0.2-1.el9
CVE-2023-20197 ClamAV File Scanning Infinite Loop Denial of Service Vulnerability