note that one of the dependencies is gnome-vfs2, itself a dependency for libgnome, which is a dependency for another dozen packages. All of them will likely go away because gnome-vfs2 is unlikely to be changed. Simo. On Wed, 2020-09-16 at 12:56 -0400, Simo Sorce wrote: > Do we need a more involved plan than filing bugs for those packages and > let them drop if they do not react ? > > I mean they are using very old dependencies, there are probably many > other ways in which they are broken at this point. > > Simo. > > On Wed, 2020-09-16 at 16:37 +0000, Gwyn Ciesla via devel wrote: > > I'm the compat-openssl10 owner. I've updated kqoauth-qt5 and sipp, > > but the rest are more involved. We need a plan for each package to be > > patched, updated to a version supporting modern openssl, or retired. > > > > > > -- > > Gwyn Ciesla > > she/her/hers > > ------------------------------------------------ > > in your fear, seek only peace > > in your fear, seek only love > > -d. bowie > > > > Sent with ProtonMail Secure Email. > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Wednesday, September 16, 2020 11:32 AM, Simo Sorce <simo@xxxxxxxxxx> wrote: > > > > > On Wed, 2020-09-16 at 14:58 +0200, Miro Hrončok wrote: > > > > > > > On 16. 09. 20 14:29, Simo Sorce wrote: > > > > > > > > > Indeed compat-openssl10 really should go. > > > > > If there are still packages depending on it they should be ported or > > > > > dropped at this point. > > > > > Openssl1.0.2 is unmaintained upstream and only critical security fixes > > > > > are done in RHEL. But the team that handles them does not own the > > > > > Fedora package anymore. OpenSSL 1.0 does not support things lie TLS 1.3 > > > > > or system-wide crypto policies. > > > > > Frankly at this point it is just a liability to continue offering it. > > > > > I'll file a bugzilla to ask to retire it from rawhide. > > > > Even if that's the case we should not just retire packages without coordinating > > > > with the dependent ones, with an exception of legal requirements. > > > > There should be a deprecation period, Fedora change or a direct communication > > > > with the package maintainers of the dependent packages, not a direct retirement. > > > I am not the package owner, I can only ask if the package owner can do > > > that. > > > However this is the list of dependent packages repoquery returns me for > > > ... > > > > > > Fedora 32: > > > dmg2img-0:1.6.7-8.fc32.x86_64 > > > freerdp1.2-0:1.2.0-14.fc32.x86_64 > > > gnome-vfs2-0:2.24.4-30.fc32.x86_64 > > > gnome-vfs2-smb-0:2.24.4-30.fc32.x86_64 > > > gq-0:1.3.4-37.fc32.x86_64 > > > httperf-0:0.9.0-25.fc32.x86_64 > > > ipsec-tools-0:0.8.2-17.fc32.x86_64 > > > kqoauth-qt5-0:0.98-0.6.20140122git7c31a12.fc32.x86_64 > > > libwvstreams-0:4.6.1-32.fc32.x86_64 > > > netty-tcnative-0:1.1.30-15.fc32.x86_64 > > > pgadmin3-0:1.22.2-18.fc32.x86_64 > > > sipp-0:3.6.0-3.fc32.x86_64 > > > skipfish-0:2.10-0.22.b.fc32.x86_64 > > > snownews-0:1.5.12-23.fc32.x86_64 > > > sscep-0:0.6.1-10.20160525git2052ee1.fc31.x86_64 > > > sslscan-0:1.11.11-5.fc32.x86_64 > > > stud-0:0.3-18.20120814git.fc32.x86_64 > > > telepathy-salut-0:0.8.1-19.fc32.x86_64 > > > ucommon-0:7.0.0-13.fc32.x86_64 > > > validns-0:0.8-14.fc32.x86_64 > > > vtun-0:3.0.4-10.fc32.x86_64 > > > > > > Fedora 33: > > > dmg2img-0:1.6.7-9.fc33.x86_64 > > > gnome-vfs2-0:2.24.4-32.fc33.x86_64 > > > gnome-vfs2-smb-0:2.24.4-32.fc33.x86_64 > > > gq-0:1.3.4-39.fc33.x86_64 > > > httperf-0:0.9.0-26.fc33.x86_64 > > > kqoauth-qt5-0:0.98-0.7.20140122git7c31a12.fc33.x86_64 > > > libwvstreams-0:4.6.1-33.fc33.x86_64 > > > netty-tcnative-0:1.1.30-17.fc33.x86_64 > > > samdump2-0:3.0.0-19.fc33.x86_64 > > > sipp-0:3.6.0-4.fc33.x86_64 > > > skipfish-0:2.10-0.23.b.fc33.x86_64 > > > snownews-0:1.5.12-24.fc33.x86_64 > > > sslscan-0:1.11.11-6.fc33.x86_64 > > > stud-0:0.3-20.20120814git.fc33.x86_64 > > > telepathy-salut-0:0.8.1-21.fc33.x86_64 > > > ucommon-0:7.0.0-15.fc33.x86_64 > > > validns-0:0.8-14.fc32.x86_64 > > > vtun-0:3.0.4-11.fc33.x86_64 > > > > > > It looks like there are a few packages that are not moving as they > > > should. But I do not think we should support them if they do not move > > > to on on something as critical as a security dependency, it is symptom > > > that they may be broken elsewhere too. > > > > > > HTH, > > > Simo. > > > > > > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > > > Simo Sorce > > > RHEL Crypto Team > > > Red Hat, Inc > > > > > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > > > > _______________________________________________ > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > > -- > Simo Sorce > RHEL Crypto Team > Red Hat, Inc > > > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
