Re: F21 System Wide Change: Workstation: Enable Software Collections
On Wed, 2014-06-04 at 16:51 +0200, Miloslav Trmač wrote: 2014-06-03 22:46 GMT+02:00 Adam Williamson awill...@redhat.com: On Sun, 2014-04-20 at 18:56 +0200, Kevin Kofler wrote: Jaroslav Reznik wrote, on behalf of Matthias Clasen: The Software Collections repositories will be enabled by default. So we now allow shipping the configuration for third-party repositories, even enabled by default? Is April 1st still not over yet? If you want those packages in Fedora, they need to get into the Fedora repository. THREAD NECRO ALERT I wouldn't put it as strongly as Kevin, but I do have some concerns about the implications here. Note that there was a lot of discussion about this ( https://fedorahosted.org/fesco/ticket/1297 and meeting logs), resulting in “merging” this Change proposal into the main SCL one in a way that makes the original text of this proposal no longer relevant. (In particular, AFAIK the full story is that SCLs will be available through Playground, and Playground requires an explicit action to enable.) That does not *entirely* dismiss your concern, though. Thanks. I missed the follow-up in other locations. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Deprecate setjmp/longjmp? [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]
On Wed, 2014-06-04 at 21:15 -0400, Sam Varshavchik wrote: Adam Williamson writes: Sam, this was clearly a half-baked thought Lennart threw out in passing. It wasn't a formal proposal. I don't think there was any danger of anyone possibly considering that. It's bad enough that Slashdot et al pick this stuff up and then badly misrepresent it; having our own list participants invoke/encourage that kind of thing doesn't seem at all useful to me. I don't think a message here can either make that happen or not make that happen. I think it can make it *slightly more likely* to happen. But if it were to happen, whose fault would that ultimately be?(*) Slashdot's, of course. But when we know something is a bad thing, if we can make it less likely to happen without losing anything of value (i.e. by not posting stuff like just wait till slashdot gets a hold of this!) we might as well. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Maybe it's time to get rid of tcpwrappers/tcpd?
On 20/03/14 20:05, Lennart Poettering wrote: On Thu, 20.03.14 12:20, Stephen John Smoogen (smo...@gmail.com) wrote: I doubt there are many people even using them anymore, firewalls are more comprehensive and a lot more powerful, and while every admin knows firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever actively make use of them... Actually they are used quite a bit in various service worlds. Mainly for ssh and email for dealing with scanners. [DenyHosts is a boon in this area.] The reason for using a secondary tool is that depth of security. Well, all mails servers as well as sshd have much better ways to do such filtering. sshd has Match, Postfix for example has smtpd_client_restrictions=, and so on. Again, I have no doubt that some people still use tcpwrappers. But I'd argue that is clearly the excpetion, not the rule, and they'd better use something different, and that we should be creating an excellent distro, instead of a one that features horrible software... Over the years I have found that there are multiple of attacks which will nullify one layer of protection at one point or another. Having a second level or third level of protection is a boon when this happens. Well, it certainly makes sense to combine a firewall with let's say selinux with maybe postfix/ssh acls. Then you already have three layers of protection, of very good protection. But of all possible options tcpwrap is the absolute worst choice. And we should be able to deprecate and remove stuff from our core OS if we think it is crap. I mean, there are two sides of the medal: sure multiple layers of protection might be a good thing, but you also make things a lot more complex with each one, and you involve more possibly exploitable code -- and tcpwrap is simply bad code, that's a fact. So you have to balance things out: is something a layer that is worth the trouble? Or does having it around make things worse? I am of the opinion that tcpwrap indeed does make things worse. I happen to share Stephens concerns. I think tcpwrappers is a good additional security layer. And I honestly don't buy the idea that code which is 11 years old is crap by default. If it has gone 11 years, being widely used by several services (including high-profile services such as SSH), that tells me something about the quality of the *performing* code. New code is better just because it's new. That we have a firewall layer which resides in the application level is a plus. Netfilter/iptables and SELinux are in kernel space, tcpwrapper is in the user-space. Yes, more layers adds complexity. But adding more security layers usually doesn't make any setups less complicated. Managing security properly is a complicated task. I would further like to hear *how* you mean tcpwrappers make things worse. You just state it, you don't provide any arguments supporting it. And comparing code and condoms is just as clever as comparing age and wisdom. -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Qt packages necessaries to develop for Android
Isaac Cortés González wrote: But it is licensed under an Apache license, we can download the source and build it ourselves. Yes, please contact the Replicant folks for how to rebuild the Android SDK from source. (Last I checked, they didn't document the procedure either, but they should know how to do it because they ship a rebuilt SDK.) We cannot ship Google's binaries, both because of the license of the binaries and because Fedora does not ship upstream binaries by policy. We have to build the SDK from source code (which will land in the SRPM, so it needs to be free from non-Free or patent-encumbered (e.g. MP* codecs) code; any bad code needs to be ripped out from the tarball). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Qt packages necessaries to develop for Android
On Thu, Jun 5, 2014 at 4:16 PM, Kevin Kofler kevin.kof...@chello.at wrote: Isaac Cortés González wrote: But it is licensed under an Apache license, we can download the source and build it ourselves. Yes, please contact the Replicant folks for how to rebuild the Android SDK from source. (Last I checked, they didn't document the procedure either, but they should know how to do it because they ship a rebuilt SDK.) We cannot ship Google's binaries, both because of the license of the binaries and because Fedora does not ship upstream binaries by policy. We have to build the SDK from source code (which will land in the SRPM, so it needs to be free from non-Free or patent-encumbered (e.g. MP* codecs) code; any bad code needs to be ripped out from the tarball). The ripping things out of tarballs policy seems really weird to me. It means, for example, that I can't compare the hash of the openssl tarball to upstream's. Is it really necessary? I understand that Fedora can't ship anything infringes on a patent, but I had the distinct impression that patents didn't cover uncompiled source code. It would be a lot simpler if it were sufficient to merely patch it out in %prep or something. Even for not-quite-free stuff, there are weird cases. For example, globalplatform's tarball [1] includes a couple of binaries. There is actually source available, and the license is fine, but the source isn't in the tarball. [2] I seriously doubt that Fedora would infringe on anyone's rights by leaving the tarball as is in the SRPM, but doing so is currently against policy. The binary RPMs would be identical either way. Of course, if there is actually stuff in the tarball that isn't redistributable, that's a different story. If this is something that shouldn't be discussed here, I'll shut up. [1] I'm thought about resurrecting this package, but dealing with hacked up tarballs is such a mess that I don't really want to. [2] I've never actually tried to build the thing, but I wouldn't want to install the binary on anyone's system anyway. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Qt packages necessaries to develop for Android
Andrew Lutomirski wrote: The ripping things out of tarballs policy seems really weird to me. It means, for example, that I can't compare the hash of the openssl tarball to upstream's. Is it really necessary? I understand that Fedora can't ship anything infringes on a patent, but I had the distinct impression that patents didn't cover uncompiled source code. Your impression is incorrect, afaik, ianal, yada yada. Everything fedora ships needs to be freely re-distributable, including the source code. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Qt packages necessaries to develop for Android
On Fri, Jun 6, 2014 at 4:00 AM, Rex Dieter rdie...@math.unl.edu wrote: Andrew Lutomirski wrote: The ripping things out of tarballs policy seems really weird to me. It means, for example, that I can't compare the hash of the openssl tarball to upstream's. Is it really necessary? I understand that Fedora can't ship anything infringes on a patent, but I had the distinct impression that patents didn't cover uncompiled source code. Your impression is incorrect, afaik, ianal, yada yada. [citation needed] Everything fedora ships needs to be freely re-distributable, including the source code. Well he said Of course, if there is actually stuff in the tarball that isn't redistributable, that's a different story. .. We have been shipping patented code in freetype for a while (until it expired) we just disabled it at build time. So I simply do not know whether the remove patented code from he tarball is simply paranoia or there is really a legal reason for it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1104721] perl-CGI-Application-Plugin-RateLimit-1.0-10.fc21 FTBS: t/03complex.t fails randomly
https://bugzilla.redhat.com/show_bug.cgi?id=1104721 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|emman...@seyman.fr |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=HBaU4soBDFa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1104721] perl-CGI-Application-Plugin-RateLimit-1.0-10.fc21 FTBS: t/03complex.t fails randomly
https://bugzilla.redhat.com/show_bug.cgi?id=1104721 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-CGI-Application-Plugin ||-RateLimit-1.0-11.fc21 Resolution|--- |RAWHIDE Last Closed||2014-06-05 04:27:22 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=S0lmIfPGxFa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1105023] New: perl-IO-Event-0.813-1.fc21 FTBFS: t/forked2.t fails under heavy load
https://bugzilla.redhat.com/show_bug.cgi?id=1105023 Bug ID: 1105023 Summary: perl-IO-Event-0.813-1.fc21 FTBFS: t/forked2.t fails under heavy load Product: Fedora Version: rawhide Component: perl-IO-Event Assignee: emman...@seyman.fr Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org External Bug ID: CPAN 92200 perl-IO-Event-0.813-1.fc21 fails t/forked2.t test if the host is under heavy load: # Looks like you planned 115 tests but ran 111. print 960: Connection reset by peer Compilation failed in require at t/forked2.t line 5. t/forked2.t . Dubious, test returned 255 (wstat 65280, 0xff00) Failed -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=w63G8VqG0Va=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1105161] New: perl-Date-Manip-6.45 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1105161 Bug ID: 1105161 Summary: perl-Date-Manip-6.45 is available Product: Fedora Version: rawhide Component: perl-Date-Manip Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 6.45 Current version/release in Fedora Rawhide: 6.43-1.fc21 URL: http://search.cpan.org/dist/Date-Manip/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Fm2rdMsRtPa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1105167] New: perl-Filter-1.50 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1105167 Bug ID: 1105167 Summary: perl-Filter-1.50 is available Product: Fedora Version: rawhide Component: perl-Filter Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 1.50 Current version/release in Fedora Rawhide: 1.49-5.fc21 URL: http://search.cpan.org/dist/Filter/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=jMrJP31o5ta=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1105167] perl-Filter-1.50 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1105167 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Filter-1.50-1.fc21 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This is a bug-fix release suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=yVXKXOsryNa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1105167] perl-Filter-1.50 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1105167 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-Filter-1.50-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-Filter-1.50-1.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=d5l8j8Tvida=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1105167] perl-Filter-1.50 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1105167 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Filter-1.50-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Filter-1.50-1.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=DVSfKmctgva=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1094440] CVE-2014-3230 perl-libwww-perl: incorrect handling of SSL certificate verification
https://bugzilla.redhat.com/show_bug.cgi?id=1094440 Tomas Hoger tho...@redhat.com changed: What|Removed |Added Priority|high|medium Whiteboard|impact=important,public=201 |impact=moderate,public=2014 |40501,reported=20140501,sou |0501,reported=20140501,sour |rce=debian,cvss2=5.8/AV:N/A |ce=debian,cvss2=5.8/AV:N/AC |C:M/Au:N/C:P/I:P/A:N,fedora |:M/Au:N/C:P/I:P/A:N,fedora- |-all/perl-libwww-perl=affec |all/perl-libwww-perl=affect |ted,rhel-5/perl-libwww-perl |ed,rhel-5/perl-libwww-perl= |=notaffected,rhel-6/perl-li |notaffected,rhel-6/perl-lib |bwww-perl=notaffected,rhel- |www-perl=notaffected,rhel-7 |7/perl-libwww-perl=affected |/perl-libwww-perl=affected Severity|high|medium --- Comment #14 from Tomas Hoger tho...@redhat.com --- (In reply to Vincent Danen from comment #0) This issue did not affect the versions of perl-libwww-perl as shipped with Red Hat Enterprise Linux 5 and 6. It should be noted that versions of perl-libwww-perl in Red Hat Enterprise Linux 6 do not perform SSL certificate verification by default (see bug 705044, including an example of how to enable certificate checks in IO::Socket::SSL in bug 705044 comment 7). The change to enable SSL verification by default was made upstream in version 6.0. Upstream version 6.0 also introduced ways to control certificate verification: - Via LWP::UserAgent ssl_opts attribute: http://search.cpan.org/dist/libwww-perl/lib/LWP/UserAgent.pm#ATTRIBUTES These allow specifying a path to file (SSL_ca_file) or directory (SSL_ca_path) with CA certificates, and whether host name verification should be performed (verify_hostname). If these are not set in a script, environment variables are checked in the following order: - PERL_LWP_SSL_* variables first, including: PERL_LWP_SSL_VERIFY_HOSTNAME, PERL_LWP_SSL_CA_FILE, and PERL_LWP_SSL_CA_PATH - HTTPS_CA_* if PERL_LWP_SSL_* are not set: HTTPS_CA_FILE, and HTTPS_CA_DIR. When these are used, host name verification is automatically disabled (for backwards compatibility). The problem here is that when host name verification is disabled, certificate verification is disabled as well (unless explicitly requested using IO::Socket::SSL's SSL_verify_mode). One such example is the use of HTTPS_CA_* environment variables. LWP::UserAgent documentation is scarce and ambiguous in defining whether verify_hostname 0 is supposed to only disable hostname check, or all certificate checks. The code seems to assume all checks are disabled. However, that's not really compatible with the (undocumented) assumption that HTTPS_CA_* environment variables are meant to enable certificate checks and only disable hostname checks. Note that use when certificate is checked without checking hostname is usually insecure, as malicious site can obtain SSL certificate from a trusted CA for a different name and still have it accepted as valid for different host. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=k841EpU7Msa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
