Re: HEADS UP: dhcp will ship bunded bind libraries
On 10. 3. 2019 19:59, Tomasz Kłoczko wrote: > On Thu, 28 Feb 2019 at 14:11, Neal Gompa wrote: > [..] >>> tl;dr dhcp 4.4.1 will not require bind-export-libs and will bring >>> dhcp-libs-static with bundled version of libisc/libdns/etc >>> >>> As ISC dropped support of single thread build of BIND libraries [1] and >>> dhcp requires one we decided to not patch dhcp/bind build scripts anymore >>> and ship bundled bind libraries just like upstream (ISC) does it. It will >>> allow to update BIND in Fedora to newest version. So dhcp 4.4.1 can be >>> expected in rawhide/F31 soon! >>> I'm aware of FPG recommendation to avoid shipping of bundled libraries due >>> to its maintenance cost but maintaining of heavy patched build sctipts and >>> inability to ship newer versions are even worse. >>> >>> I have not find any application in Fedora repository which link with >>> libdhcp/libomapi. Please let me know if you aware of any. >>> >> Just add the bundled() Provides if it's building with bundled copies, >> per the policy: >> https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling > > I'm only curious (maybe I do not understand something about this > issue) .. why dhcpd cannot use standard glibc resolver? > IIRC glibc libresolve is thread safe (if this issue it is about thread > safe DNS resolution). > Can someone explain that topic a bit? > > kloczek > ISC DHCP uses BIND libraries e.g. to support Dynamic DNS updates on authoritative DNS server when assigning leases to hosts. I don't think that glibc resolver would be anyhow useful in this case. Regards, Tomas -- Tomas Hozza Associate Manager, Software Engineering - EMEA ENG Core Services PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned python-adns
Hi all. I just orphaned python-adns. I don't need it and don't plan to maintain it. The last upstream release was in 2007 and it does not support Python3. Also it FTBFS in rawhide. python-adns is required by transmission-remote-cli. Please consider removing the dependency, so that python-adns can be retired or please consider maintaining python-adns as well. Regards, Tomas -- Tomas Hozza Associate Manager, Software Engineering - EMEA ENG Core Services PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F26 Self Contained Change: BIND version 9.11
On 10/09/2016 09:58 PM, Peter Robinson wrote: > On Mon, Oct 3, 2016 at 11:18 AM, Jan Kurik <jku...@redhat.com> wrote: > > = Proposed Self Contained Change: BIND version 9.11 = > > https://fedoraproject.org/wiki/Changes/BIND_9.11 > > > > Change owner(s): > > * Tomas Hozza > > * Michal Ruprich > > > > BIND (Berkeley Internet Name Domain) version 9.11 is the latest stable > > major update of the widely used DNS server. Besides new features, some > > settings defaults have changed since the previous major version > > (9.10). > > > > == Detailed Description == > > FULL BIND 9.11 RELEASE NOTES: > > ftp://ftp.isc.org/isc/bind9/9.11.0b3/RELEASE-NOTES-bind-9.11.0b3.txt > > > > New features > > * A new method of provisioning secondary servers called "Catalog > > Zones" has been added. > > * Added an isc.rndc Python module, which allows rndc commands to be > > sent from Python programs. > > * Added support for DynDB, a new interface for loading zone data from > > an external database, developed by Red Hat for the FreeIPA project. > > * New quotas have been added to limit the queries that are sent by > > recursive resolvers to authoritative servers experiencing > > denial-of-service attacks. > > * Added support for dnstap, a fast, flexible method for capturing and > > logging DNS traffic. > > * A new DNSSEC key management utility, dnssec-keymgr, has been added. > > * nslookup will now look up IPv6 as well as IPv4 addresses by default. > > * named will now check to see whether other name server processes are > > running before starting up. > > * Added server-side support for pipelined TCP queries. > > * The new mdig command is a version of dig that sends multiple > > pipelined queries and then waits for responses, instead of sending one > > query and waiting the response before sending the next. > > * A new message-compression option can be used to specify whether or > > not to use name compression when answering queries. > > * When loading a signed zone, named will now check whether an RRSIG's > > inception time is in the future, and if so, it will regenerate the > > RRSIG immediately. > > > > Feature changes > > * When using native PKCS#11 cryptography (i.e., configure > > --enable-native-pkcs11) HSM PINs of up to 256 characters can now be > > used. > > * Update forwarding performance has been improved by allowing a single > > TCP connection to be shared between multiple updates. > > * Added support for OPENPGPKEY type. > > * Retrieving the local port range from net.ipv4.ip_local_port_range on > > Linux is now supported. > > * On machines with 2 or more processors (CPU), the default value for > > the number of UDP listeners has been changed to the number of detected > > processors minus one. > > * Zone transfers now use smaller message sizes to improve message > > compression. This results in reduced network usage. > > * Added support for the AVC resource record type (Application > > Visibility and Control). > > > > == Scope == > > Proposal owners: > > * Rebase the package to the latest 9.11 minor version and resolve > > possible packaging issues. (Also rebuild all currently existing > > dependent packages listed below) > > Any idea if we can move back to building the dhcp package against the > latest version and retire bind99? I don't remember the exact bugs we > saw against 9.10 with dhcp (although I do vaguely remember some issue > that forced the change). > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Hello Peter. ISC DHCP can be built only against BIND libraries from major version 9.9.x. In 9.9.x version they built separate "external" version of libraries, which are used by DHCP. In newer BIND versions they are building only a single version of libraries (in which they removed bunch of #IFDEFs), but unfortunately these libraries are not usable for building DHCP at this moment. ISC has other priorities at this point, as they bundle BIND sources with DHCP tarball and BIND of version 9.9.x is supported until end of 2017. So short answer is NO, we can not retire bind99 because it is not possible to build DHCP against BIND 9.10.x nor 9.11.x. Nevertheless bind99 is a stripped down version in which only the necessary libraries are built, without building BIND itself or any other BIND utility. So technically we have only a single version of BIND in the distribution. Short story long (the FPC ticket which granted the exception for bind99) -> https://fedorahosted.org/fpc/ticket/502 Regards, Tomas -- Tomas Hozza Associate Manager, Software Engineering - EMEA ENG Mainstream RHEL PGP: 1D9F3C2D UTC+2 (CEST) Red Hat Inc. http://cz.redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bind update (CVE-2016-2776)?
On 09/29/2016 10:36 AM, Igor Gnatenko wrote: > On Thu, Sep 29, 2016 at 10:08 AM, Tomas Hozza <tho...@redhat.com> wrote: > > On 09/29/2016 06:19 AM, Bojan Smojver wrote: > >> Could someone with sufficient access please spin up an update of bind > >> for F-24 and other flavours of Fedora. That CVE looks like a pretty > >> serious DoS. This has already been fixed in RHEL. > >> > >> Thanks, > >> > > > > Hi. > > > > I'll be pushing the updates shortly. The problem with Fedora is that we can > > not prepare the update in advance as for RHEL, because everything (git > > repos, update system, etc.) is public. > You mean before CVE has been published? Or what's the problem with being > public? Yes, that's what I meant. Tomas > > > > Regards, > > Tomas > > -- > > Tomas Hozza > > Associate Manager, Software Engineering - EMEA ENG Mainstream RHEL > > > > PGP: 1D9F3C2D > > UTC+2 (CEST) > > Red Hat Inc. http://cz.redhat.com > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > -- Tomas Hozza Associate Manager, Software Engineering - EMEA ENG Mainstream RHEL PGP: 1D9F3C2D UTC+2 (CEST) Red Hat Inc. http://cz.redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bind update (CVE-2016-2776)?
On 09/29/2016 06:19 AM, Bojan Smojver wrote: > Could someone with sufficient access please spin up an update of bind > for F-24 and other flavours of Fedora. That CVE looks like a pretty > serious DoS. This has already been fixed in RHEL. > > Thanks, > Hi. I'll be pushing the updates shortly. The problem with Fedora is that we can not prepare the update in advance as for RHEL, because everything (git repos, update system, etc.) is public. Regards, Tomas -- Tomas Hozza Associate Manager, Software Engineering - EMEA ENG Mainstream RHEL PGP: 1D9F3C2D UTC+2 (CEST) Red Hat Inc. http://cz.redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: How to fix broken dependency in orphaned package that FTBFS in F24
On 07.04.2016 15:50, James Hogarth wrote: > > > On 7 April 2016 at 14:26, Tomas Hozza <tho...@redhat.com > <mailto:tho...@redhat.com>> wrote: > > Hi all. > > We pushed an update for log4cplus in F24+ [1]. It is a rebase and one of > the dependent packages is "pion-net". The problem is that pion-net does not > build on F24+, which stops us from pushing update on F24 which would not > break dependencies. There is an older build of pion-net in F24 from times > when it was building just fine. > > What should be the process here? Should we untag the package from F24 or > should I ignore the broken dependency? I don't see any good solutions to this > problem other than fixing the FTBFS in pion-net. > > Also note that pion-net is orphaned. > > > > Well if you need it leaving it orphaned isn't going to help you (plus when it > gets retired your package will no longer meet its dependency requirements so > will need to be retired without the dep picked up). > > So as I see it options are: > 1) Pick up pion-net yourself > 2) Convince someone else to pick up pion-net > > Either way the FTBFS will need to be fixed ... unless you retire log4cplus > from F24+ ... although I'm guessing you don't want to do that. > > > > > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > Actually it is the other way around. The orphaned package pion-net depends on log4cplus. I'm not interested in taking ownership of the pion-net and actually retiring if from F24 works for me. log4cplus works as expected and is not broken, nor any of its dependencies. Only the one package which depends ON log4cplus. Regards, -- Tomas Hozza Senior Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
How to fix broken dependency in orphaned package that FTBFS in F24
Hi all. We pushed an update for log4cplus in F24+ [1]. It is a rebase and one of the dependent packages is "pion-net". The problem is that pion-net does not build on F24+, which stops us from pushing update on F24 which would not break dependencies. There is an older build of pion-net in F24 from times when it was building just fine. What should be the process here? Should we untag the package from F24 or should I ignore the broken dependency? I don't see any good solutions to this problem other than fixing the FTBFS in pion-net. Also note that pion-net is orphaned. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2016-53b6df64eb Regards, -- Tomas Hozza Senior Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On 07.12.2015 12:23, Lennart Poettering wrote: > On Mon, 07.12.15 10:48, Tomas Hozza (tho...@redhat.com) wrote: > >> On 04.12.2015 15:57, Lennart Poettering wrote: >>> On Tue, 01.12.15 11:15, Tomas Hozza (tho...@redhat.com) wrote: >>> >>>> You are not mistaken. >>>> >>>> This is the third time, because previously we rather moved the change to >>>> the >>>> next Fedora to bring better user experience. Every time there was something >>>> enhanced, since we learned a lot about user use-cases, so this is >>>> definitely >>>> not the same change as before, only the root idea is the same. The Change >>>> Wiki >>>> is up-to-date and contains the current information. >>>> >>>> Also with many projects involved - Gnome Shell, NetworkManager, Unbound, >>>> dnssec-trigger, SELinux (always a pleasure:), Docker... it is not the >>>> easiest >>>> thing to agree on changes and coordinate everything on time. >>> >>> So, here's a question: in germany "Fritzbox" wifi routers are very >>> popular. Their configuration page is reachable under the "fritz.box" >>> pseudo-domain from inside their wifi network, and all other systems on >>> the network are also eachable below this domain under their >>> DHCP-configured hostnames. It implements a DNS proxy otherwise, only >>> synthesizing A/ RRs for *.box. Now, one can certainly argue that >>> this is borked, since the manufacturer doesn't own the ".box" domain, >>> but discussing this is pretty pointless, as the fact that this is what >>> is deployed in probably half of the homes in Germany... Also I am >>> pretty sure other routers form other manufacturers do the same >>> thing. Now, if we default to DNSSEC validation soon, does this mean >>> people won't be able to configure their wifi routers anymore, or reach >>> other systems on their home networks anymore, because the NSEC/NSEC3 >>> RRs in the root domain claim .box does not exist? What's your >>> strategy there? Why do you think DNSSEC is worth breaking pretty much >>> everybody's network? Note that Fritzbox is not a random crappy router, >>> it's probably of the better products you can find. >> >> As you've said, this is basically an attack and hijacking of someone's >> else domain name space. It is not correct and it is not expected that >> this will work with DNSSEC. > > Humm, I find that way too cavalier... I am pretty sure this is a total > deal breaker for your feature. You cannot just break everybody's > network and not consider that a problem that *you* have to think about > rather than just ignoring it completely. It sounds like you stopped at the first section of the email and ended there. I didn't said that, and if you read the whole email you should understand that. Otherwise my email would end right after this section you commented to. > The ".box" domain is not owned by anyone, at least currently, it's > certainly not "hijacking" of anybody else's domain name space. You hijack the root zone space. > But it really doesn't matter whether that's hijacking or not. What > matters is that a large number of setups are like that... And you > break them by default, and apparently don't consider this a problem. I didn't said that. > Quite frankly: a setup like this one isn't just very typical for home > router networks, but also in many companies, where ".lan" or > ".companyname" or something like that is frequently established in the > internal network. And you will make Fedora incompatible with all these > networks by default. > > The way you proposed your feature this has no place at all on the > desktop I am sure, where systems migrate between networks all the > time, and sometimes quite shitty networks. I am very sure that most > Fedora users would prefer their internet to work, rather than be > "pretend-safe", after all DNSSEC is neither necessary for safe > connections nor enables otherwise unsafe connections to be suddenly > safe... > > Your feature has no place on the server the way it is either, > because those are often enough located in some company network with > internal DNS zones. Lennart, you don't have to comment on something you think I said, while the rest of my email described the possible solution to the problem. This means that I think it is important to take it into account and provide some possible solution. >> I think we could extend the module with an option to configure list of >> domains >> for
Re: F24 System Wide Change: Default Local DNS Resolver
On 07.12.2015 14:52, Matthew Miller wrote: > On Mon, Dec 07, 2015 at 12:23:34PM +0100, Lennart Poettering wrote: > >> As you've said, this is basically an attack and hijacking of someone's > >> else domain name space. It is not correct and it is not expected that > >> this will work with DNSSEC. > > Humm, I find that way too cavalier... I am pretty sure this is a total > > deal breaker for your feature. You cannot just break everybody's > > network and not consider that a problem that *you* have to think about > > rather than just ignoring it completely. > > I agree with Lennart. Whether or not this is expected to work with > DNSSEC is of academic interest given that people will expect it to work > with _their computers_, regardless of what they're running. I guess next time I'll not send thing to devel list that I don't want to be picked on. This is completely out of context. Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On 07.12.2015 15:15, Richard Hughes wrote: > On 7 December 2015 at 14:04, Tomas Hozza <tho...@redhat.com> wrote: >> I took this conversation as a mean for improvement. > > When an email is titled "F24 System Wide Change" I think a lot of > people (like me) were under the impression you wanted this to be a new > feature in Fedora 24. When I reply to an email that was a reply to my previous email, I take it as a discussion. Sorry for confusing you. Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On 07.12.2015 15:00, Matthew Miller wrote: > On Mon, Dec 07, 2015 at 02:59:18PM +0100, Tomas Hozza wrote: > >> I agree with Lennart. Whether or not this is expected to work with > >> DNSSEC is of academic interest given that people will expect it to work > >> with _their computers_, regardless of what they're running. > > I guess next time I'll not send thing to devel list that I don't want > > to be picked on. This is completely out of context. > > Am I misunderstanding something? It seems like a valid concern to me. Besides that my email started with the fact that it is what it is, whether you like it or not, I continued with the possibilities we have. I took this conversation as a mean for improvement. But it turned out to be PR for systemd-resolved. Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On 07.12.2015 16:44, Andrew Lutomirski wrote: > > On Dec 7, 2015 1:49 AM, "Tomas Hozza" <tho...@redhat.com > <mailto:tho...@redhat.com>> wrote: > > > > On 04.12.2015 15:57, Lennart Poettering wrote: > > > On Tue, 01.12.15 11:15, Tomas Hozza (tho...@redhat.com > > > <mailto:tho...@redhat.com>) wrote: > > > > > >> You are not mistaken. > > >> > > >> This is the third time, because previously we rather moved the change to > > >> the > > >> next Fedora to bring better user experience. Every time there was > > >> something > > >> enhanced, since we learned a lot about user use-cases, so this is > > >> definitely > > >> not the same change as before, only the root idea is the same. The > > >> Change Wiki > > >> is up-to-date and contains the current information. > > >> > > >> Also with many projects involved - Gnome Shell, NetworkManager, Unbound, > > >> dnssec-trigger, SELinux (always a pleasure:), Docker... it is not the > > >> easiest > > >> thing to agree on changes and coordinate everything on time. > > > > > > So, here's a question: in germany "Fritzbox" wifi routers are very > > > popular. Their configuration page is reachable under the "fritz.box" > > > pseudo-domain from inside their wifi network, and all other systems on > > > the network are also eachable below this domain under their > > > DHCP-configured hostnames. It implements a DNS proxy otherwise, only > > > synthesizing A/ RRs for *.box. Now, one can certainly argue that > > > this is borked, since the manufacturer doesn't own the ".box" domain, > > > but discussing this is pretty pointless, as the fact that this is what > > > is deployed in probably half of the homes in Germany... Also I am > > > pretty sure other routers form other manufacturers do the same > > > thing. Now, if we default to DNSSEC validation soon, does this mean > > > people won't be able to configure their wifi routers anymore, or reach > > > other systems on their home networks anymore, because the NSEC/NSEC3 > > > RRs in the root domain claim .box does not exist? What's your > > > strategy there? Why do you think DNSSEC is worth breaking pretty much > > > everybody's network? Note that Fritzbox is not a random crappy router, > > > it's probably of the better products you can find. > > > > As you've said, this is basically an attack and hijacking of someone's > > else domain name space. It is not correct and it is not expected that > > this will work with DNSSEC. > > > > Now, we realized some time ago, that there are situations where the > > local network-provided resolvers should be used to some extent, even > > if they don't support DNSSEC. We think that such resolvers could be > > used for INSECURE or INDETERMINATE answers and requeried. This would > > allow you to use the local resources from the network. > > > > Obviously this would not work with TLDs, since the root zone is signed > > and therefore you should never get an INSECURE answer for TLD. The same > > for any non-existing subdomain of a signed domain, etc. > > > > The mechanism of using the network provided resolvers is something > > we were trying to get into the "DNSSEC roadblock avoidance" IETF > > RFC draft [1]. We have an experimental "mixed-mode" [2] module for Unbound, > > however it is still not in upstream, because we were waiting for the > > algorithm to get into the RFC draft. > > > > I think we could extend the module with an option to configure list of > > domains > > for which you would like to fallback to the local resolvers, even if the > > answer was SECURE. This could be used for the non-existing or "abused" TLDs. > > Note that IETF is thinking about reserving some of such domains as private > > [3], > > so once it is standardized, it could be done for these automatically. > > > > Can you elaborate a bit? Is the intent that, if .box were private, then .box > would be forwarded to DHCP-provided revolvers regardless of whether those > resolvers were functional when asking for DNSSEC signature data? > > If so, what cases does this not cover? It fails in the split-horizon > DNSSEC-enabled case where the domain owner hasn't set it up right, but I'd > argue that that's a good thing. I think that explicit list of domains would cover pretty much any use-case. We were thinking about configuring the
Re: F24 System Wide Change: Default Local DNS Resolver
On 05.12.2015 18:57, Florian Weimer wrote: > On 11/30/2015 05:14 PM, Jan Kurik wrote: >> We want to have Unbound server installed and running on localhost by >> default on Fedora systems. Where necessary, have also dnssec-trigger >> installed and running by default > > Would someone please clarify the proposal if Unbound would run as a > forwarder, or as a stand-alone recursive resolver? It depends on the network. If the resolvers from the DHCP are usable for DNSSEC, then these will be used as forwarders. Nevertheless, Unbound does the validation locally, so it will query for all the necessary data to build the chain of trust. In case the network-provided resolvers are not usable for DNSSEC, then Unbound is configured to do the recursion. In case this is blocked on the network, Unbound is configured to tunnel the DNS queries to Fedora public infrastructure over TCP (80, 443) or SSL (443), in which case this is similar to the first situation, when Unbound forwards queries to the resolvers, but does the validation locally. This is part of dnssec-trigger documentation, since it is used as the mean to reconfigure Unbound. Tomas > Thanks, > Florian > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Layered Docker Image Build Service
On 03.12.2015 15:40, Adam Miller wrote: > On Thu, Dec 3, 2015 at 8:12 AM, Tomas Hozza <tho...@redhat.com> wrote: > > On 03.12.2015 14:54, Jan Kurik wrote: > >> On Thu, Dec 3, 2015 at 2:38 PM, Tomas Hozza <tho...@redhat.com> wrote: > >>> On 03.12.2015 11:40, Jan Kurik wrote: > >>>> = Proposed System Wide Change: Layered Docker Image Build Service = > >>>> https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service > >>>> > >>>> Change owner(s): > >>>> * Colin Walters > >>>> * Adam Miller > >>>> * Tomas Tomecek > >>>> * Tim Waugh > >>>> * Amanda Carter > >>>> > >>>> Fedora currently ships a Docker base image, but Docker supports a > >>>> layering concept. There are some applications like Cockpit which we > >>>> would like to ship as layered applications. > >>>> This change will deploy the build service to support building and > >>>> delivering a set of layered Docker images, and will enable Fedora > >>>> contributors to create and maintain Dockerfiles from which those > >>>> images will be generated. > >>>> > >>>> == Detailed Description == > >>>> This change opens up an new type of official binary artifact produced > >>>> by Fedora. Currently, we produce two main types of artifacts: RPMs, > >>>> and images. The RPMs are created in Koji from specfiles in dist-git. > >>>> The images come in different formats, but have in common creation in > >>>> Koji from kickstart files — this includes the official Fedora Docker > >>>> Base Image. This change introduces a new type of image, a Docker > >>>> Layered Image, which is created from a Dockerfile and builds on top of > >>>> that base image. > >>>> > >>>> The system has five major parts: > >>>> > >>>> A command-line client — already integrated into rpkg; needs only minor > >>>> work to enable in fedpkg (there is discussion about either extending > >>>> fedpkg or adding a new fedcontainer utility) > >>>> * dist-git for Dockerfiles > >>>> * A koji plugin, containerbuild > >>>> * An OpenShift 3 backend > >>>> * A distribution mechanism; a Docker Registry > >>>> * Currently evaluating options for this > >>>> * * Pulp Crane > >>>> * * Docker Registry > >>>> > >>>> == Scope == > >>>> For the Scope of this Change please check > >>>> https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service#Scope > >>>> > >>> > >>> Hi. > >>> > >>> The "Ongoing Work Tracking" link does not work. > >> > >> Fixed. Thanks for verifying. > >> > >>> How is this different from the proposal for Fedora 23 [1]? > >>> What changed? > >> > >> It is not different. The project has started at F23 time however has > >> not been finished on time. This is continuation of the project. > > > > I'm curious to hear from the change owners if anything changed and > > what pieces that blocked this from being done last time are still pending > > and what is already done. > > It was a few things but the biggest issue was that upstream docker was > in-flight on retiring the old image format (V1) in favor of the new > one (V2) which has implications on how a "non-native" docker build > system (read: something other than the docker daemon) can > import/export docker images to and from a registry which required a > lot of re-engineering the backend of the OSBS build system. Basically > the "docker save" functionality disappeared in V2 upstream without any > replacement. This work is mostly done and the build system can work > with V2 registries now. > > I'm also not entirely sure this is a "system wide change" as others > might classify it. For people who are just using Fedora, if we missed > the deadline or messed something up, they wouldn't notice so it's > possible this needs to change in classification. Thank you for the explanation. Would regular Fedora contributors be able to create and build Layered Docker images using OSBS? Or will this be usable only for the official images produced as part of Fedora Products? E.g. if I think it would be beneficial to ship some package/service that is already shipped in Fedora as Docker image, will there
Re: F24 System Wide Change: Layered Docker Image Build Service
On 03.12.2015 11:40, Jan Kurik wrote: > = Proposed System Wide Change: Layered Docker Image Build Service = > https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service > > Change owner(s): > * Colin Walters > * Adam Miller > * Tomas Tomecek > * Tim Waugh > * Amanda Carter > > Fedora currently ships a Docker base image, but Docker supports a > layering concept. There are some applications like Cockpit which we > would like to ship as layered applications. > This change will deploy the build service to support building and > delivering a set of layered Docker images, and will enable Fedora > contributors to create and maintain Dockerfiles from which those > images will be generated. > > == Detailed Description == > This change opens up an new type of official binary artifact produced > by Fedora. Currently, we produce two main types of artifacts: RPMs, > and images. The RPMs are created in Koji from specfiles in dist-git. > The images come in different formats, but have in common creation in > Koji from kickstart files — this includes the official Fedora Docker > Base Image. This change introduces a new type of image, a Docker > Layered Image, which is created from a Dockerfile and builds on top of > that base image. > > The system has five major parts: > > A command-line client — already integrated into rpkg; needs only minor > work to enable in fedpkg (there is discussion about either extending > fedpkg or adding a new fedcontainer utility) > * dist-git for Dockerfiles > * A koji plugin, containerbuild > * An OpenShift 3 backend > * A distribution mechanism; a Docker Registry > * Currently evaluating options for this > * * Pulp Crane > * * Docker Registry > > == Scope == > For the Scope of this Change please check > https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service#Scope > Hi. The "Ongoing Work Tracking" link does not work. How is this different from the proposal for Fedora 23 [1]? What changed? [1] https://fedorahosted.org/fesco/ticket/1461 Thanks! Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Layered Docker Image Build Service
On 03.12.2015 14:54, Jan Kurik wrote: > On Thu, Dec 3, 2015 at 2:38 PM, Tomas Hozza <tho...@redhat.com> wrote: >> On 03.12.2015 11:40, Jan Kurik wrote: >>> = Proposed System Wide Change: Layered Docker Image Build Service = >>> https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service >>> >>> Change owner(s): >>> * Colin Walters >>> * Adam Miller >>> * Tomas Tomecek >>> * Tim Waugh >>> * Amanda Carter >>> >>> Fedora currently ships a Docker base image, but Docker supports a >>> layering concept. There are some applications like Cockpit which we >>> would like to ship as layered applications. >>> This change will deploy the build service to support building and >>> delivering a set of layered Docker images, and will enable Fedora >>> contributors to create and maintain Dockerfiles from which those >>> images will be generated. >>> >>> == Detailed Description == >>> This change opens up an new type of official binary artifact produced >>> by Fedora. Currently, we produce two main types of artifacts: RPMs, >>> and images. The RPMs are created in Koji from specfiles in dist-git. >>> The images come in different formats, but have in common creation in >>> Koji from kickstart files — this includes the official Fedora Docker >>> Base Image. This change introduces a new type of image, a Docker >>> Layered Image, which is created from a Dockerfile and builds on top of >>> that base image. >>> >>> The system has five major parts: >>> >>> A command-line client — already integrated into rpkg; needs only minor >>> work to enable in fedpkg (there is discussion about either extending >>> fedpkg or adding a new fedcontainer utility) >>> * dist-git for Dockerfiles >>> * A koji plugin, containerbuild >>> * An OpenShift 3 backend >>> * A distribution mechanism; a Docker Registry >>> * Currently evaluating options for this >>> * * Pulp Crane >>> * * Docker Registry >>> >>> == Scope == >>> For the Scope of this Change please check >>> https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service#Scope >>> >> >> Hi. >> >> The "Ongoing Work Tracking" link does not work. > > Fixed. Thanks for verifying. > >> How is this different from the proposal for Fedora 23 [1]? >> What changed? > > It is not different. The project has started at F23 time however has > not been finished on time. This is continuation of the project. I'm curious to hear from the change owners if anything changed and what pieces that blocked this from being done last time are still pending and what is already done. Thanks. Tomas > Regards, > Jan > >> [1] https://fedorahosted.org/fesco/ticket/1461 >> >> Thanks! >> >> Regards, >> -- >> Tomas Hozza >> Software Engineer - EMEA ENG Developer Experience >> >> PGP: 1D9F3C2D >> UTC+1 (CET) >> Red Hat Inc. http://cz.redhat.com >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > > > -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On 02.12.2015 14:03, Neal Becker wrote: > Neal Becker wrote: > >> P J P wrote: >> >>> Hello Neal, >>> >>>> On Wednesday, 2 December 2015 1:03 AM, Neal Becker wrote: >>>> For example, when I'm at work, I can access hostA.work.com >>>> where resolving hostA only works by talking to dnsserverA.work.com, >>>> which was setup by the usual dhcp and then when I'm at home >>>> >>>> google.com is resolved as normal, using my ISP's dhcp to configure dns. >>>> And this must work without the user ever editing some unbound config >>>> file. >>> >>> >>> Yes, it does work that way. The proposed solution(tools) is available >>> in >>> current Fedora repositories and is easy to set-up and test. >>> >>> >>> -> >>> >> > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test >>> >>> >>> Please let us know if you face any difficulties. Thank you. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1287607 >> >> > So remaining difficulties are: > > * howto prevent dnsmasq from starting (right now I'm just manually killing > it for testing) This is needed only if you intentionally started dnsmasq. You don't need to kill all dnsamsq instances in the system (e.g. the ones started by libvirt). I'll review the change wiki in this regard. > * howto get domainname set automatically from dhcp As discussed in the Bug, this is not going to work and it is expected not to. Setting search domains from DHCP is a security issue. Tomas > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
You are not mistaken. This is the third time, because previously we rather moved the change to the next Fedora to bring better user experience. Every time there was something enhanced, since we learned a lot about user use-cases, so this is definitely not the same change as before, only the root idea is the same. The Change Wiki is up-to-date and contains the current information. Also with many projects involved - Gnome Shell, NetworkManager, Unbound, dnssec-trigger, SELinux (always a pleasure:), Docker... it is not the easiest thing to agree on changes and coordinate everything on time. What changed from the top of my head: - We decided not to install the dnssec-trigger panel by default and rather better integrate dnssec-trigger with NM and Gnome Shell - We decided not to query user for security decisions, and for the beginning if there is no other option just fall back to the current state that that is in Fedora today - better handling of environments, where the resolvers on the network don't support DNSSEC by new Unbound plugin. This is still not in upstream, since we wanted to get the algorithm to the RFC draft that is currently discussed on IETF WG (http://www.ietf.org/id/draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt) - dnssec-trigger does not do the Captive Portal detection and handling and we rather rely on NM for the detection and on Gnome Shell for the Portal login - Some enhancements of the portal helper in Gnome Shell are being reviewed, (it will not rely on the resolv.conf content and rather use sandboxed environment with resolv.conf containing resolvers for the connection from NM). If you check the "decisions made" part of the change wiki, it discusses the important outcomes of discussions. Some of these things are not polished, implemented or merged upstream yet, but we are working on them with the F24 schedule in mind. We are also communicating with NM and Gnome devels and will discuss the defaults with WGs with some Product, once FESCo approves the change. Regards, Tomas On 01.12.2015 09:14, Vít Ondruch wrote: > If I am not mistaken, this is at least 3rd time this change is proposed. > Can somebody post some short summary what was changed, that you believe > it will be successful this time? > > Thx > > > Vít > > > Dne 30.11.2015 v 17:14 Jan Kurik napsal(a): > > = Default Local DNS Resolver = > > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver > > > > Change owner(s): > > * P J P > > * Pavel Šimerda > > * Tomas Hozza > > * Petr Špaček > > > > Plain DNS protocol is insecure and therefore vulnerable from various > > attacks (e.g. cache poisoning). A client can never be sure that there > > is no man-in-the-middle, if it does not do the DNSSEC validation > > locally. > > We want to have Unbound server installed and running on localhost by > > default on Fedora systems. Where necessary, have also dnssec-trigger > > installed and running by default. Unbound and dnssec-trigger will be > > properly integrated with the default network configuration manager > > (e.g. NetworkManager for Fedora Server and Workstation) and with the > > graphical user interface (especially GNOME). The localhost address > > will be the only record in /etc/resolv.conf and no other software > > except dnssec-trigger will be allowed to change its content. > > > > > > > > == Detailed Description == > > Plain DNS protocol is insecure and therefore vulnerable from various > > attacks (e.g. cache poisoning). DNSSEC is a DNS extension which > > enabled the client to verify the DNS query response and make sure > > there is no attacker to spoof some records. A user connected to > > network usually receives a set of resolvers from DHCP, which should be > > used for name resolution. These resolvers may also do the DNSSEC > > validation. However a client can never be sure that there is no > > man-in-the-middle, if it does not do the DNSSEC validation locally. > > Purpose of this Fedora change is to have a validating DNS resolver > > installed on Fedora systems by default. This includes necessary > > discussions, coordination and integration with other components > > installed on Fedora by default. > > > > There are growing instances of discussions and debates about the need > > for a trusted local validating DNS resolver. There are multiple > > reasons for having such a resolver, most importantly security and > > usability. Security and protection of user's privacy becomes paramount > > with the backdrop of the increasingly snooping governments and service > > providers world wide. > > > > People use Fedora on portable/mobile devices which are connected to &g
Re: F24 System Wide Change: Default Local DNS Resolver
On 01.12.2015 16:06, Björn Persson wrote: > Tomas Hozza <tho...@redhat.com> wrote: > > - dnssec-trigger does not do the Captive Portal detection and handling and > > we rather rely on NM for the detection and on Gnome Shell for the Portal > > login > > Can I assume that users of non-Gnome desktops will also be able to log > in to a portal if they want to? Yes, it should be possible. You would need to install the dnssec-trigger-panel. Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On 01.12.2015 13:28, Tomas Mraz wrote: > On Út, 2015-12-01 at 11:15 +0100, Tomas Hozza wrote: > > You are not mistaken. > > > > This is the third time, because previously we rather moved the change to the > > next Fedora to bring better user experience. Every time there was something > > enhanced, since we learned a lot about user use-cases, so this is definitely > > not the same change as before, only the root idea is the same. The Change > > Wiki > > is up-to-date and contains the current information. > > > > Also with many projects involved - Gnome Shell, NetworkManager, Unbound, > > dnssec-trigger, SELinux (always a pleasure:), Docker... it is not the > > easiest > > thing to agree on changes and coordinate everything on time. > > > > What changed from the top of my head: > > - We decided not to install the dnssec-trigger panel by default and rather > > better integrate dnssec-trigger with NM and Gnome Shell > > - We decided not to query user for security decisions, and for the beginning > > if there is no other option just fall back to the current state that that > > is > > in Fedora today > > Will there be at least some visual indicator that the network you're > connected to does not provide secure DNS? Not that the network does not provide secure DNS, but only that the local DNS resolver is not able to use DNSSEC. This information makes sense on the system level, not really on the connection level (although technically it is possible). We are still working on the solution. Nevertheless it should be native WRT the desktop environment on Fedora Workstation. Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2015-11-25)
On 25.11.2015 10:03, Tomas Hozza wrote: > Following is the list of topics that will be discussed in the FESCo > meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/UTCHowto > > or run: > date -d '2015-11-25 18:00 UTC' > > > Links to all tickets below can be found at: > https://fedorahosted.org/fesco/report/9 > > = Followups = > > > = New business = > > #topic #1500 Deactivate accounts that infra could not contact for 7 days. > .fesco 1500 > https://fedorahosted.org/fesco/ticket/1500 > > #topic #1501 F24 System Wide Change: Systemd package split > .fesco 1501 > https://fedorahosted.org/fesco/ticket/1501 > > #topic #1502 F24 System Wide Change: Systemd file triggers > .fesco 1502 > https://fedorahosted.org/fesco/ticket/1502 > > #topic #1503 F24 System Wide Change: GHC 7.10 > .fesco 1503 > https://fedorahosted.org/fesco/ticket/1503 > > = Open Floor = > > For more complete details, please visit each individual ticket. The > report of the agenda items can be found at > https://fedorahosted.org/fesco/report/9 > > If you would like to add something to this agenda, you can reply to > this e-mail, file a new ticket at https://fedorahosted.org/fesco, > e-mail me directly, or bring it up at the end of the meeting, during > the open floor topic. Note that added topics may be deferred until > the following meeting. > > Regards, > === #fedora-meeting: FESCO (2015-11-25) === Meeting started by thozza at 18:00:21 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-11-25/fesco.2015-11-25-18.00.log.html . Meeting summary --- * init process (thozza, 18:00:21) * #1500 Deactivate accounts that infra could not contact for 7 days. (thozza, 18:03:40) * AGREED: Request from ticket #1500 is approved, however please consider longer period than 1 hour between the emails. (+6, 0, -0) (thozza, 18:10:13) * #1501 F24 System Wide Change: Systemd package split (thozza, 18:10:25) * LINK: https://fedorahosted.org/fesco/ticket/1501 (thozza, 18:12:36) * AGREED: F24 System Wide Change: Systemd package split is approved (+7, 0, -0) (thozza, 18:13:39) * #1502 F24 System Wide Change: Systemd file triggers (thozza, 18:13:59) * AGREED: F24 System Wide Change: Systemd file triggers is approved (+7, 0, -0) (thozza, 18:18:31) * #1503 F24 System Wide Change: GHC 7.10 (thozza, 18:18:47) * AGREED: F24 System Wide Change: GHC 7.10 is approved (+7, 0, -0) (thozza, 18:21:15) * Next week's chair (thozza, 18:21:28) * paragan to chair next week (thozza, 18:22:36) * Open Floor (thozza, 18:22:48) * zbyszek will remove the %post script from systemd package that modifies the nsswitch.conf (thozza, 18:35:48) * ACTION: zbyszek to modify systemd %post to remove my_machines from the passwd: and group: lines in nsswitch.conf while the interaction is sorted out between glibc, IDM and systemd upstreams. (sgallagh, 18:52:47) Meeting ended at 18:56:03 UTC. Action Items * zbyszek to modify systemd %post to remove my_machines from the passwd: and group: lines in nsswitch.conf while the interaction is sorted out between glibc, IDM and systemd upstreams. Action Items, by person --- * zbyszek * zbyszek to modify systemd %post to remove my_machines from the passwd: and group: lines in nsswitch.conf while the interaction is sorted out between glibc, IDM and systemd upstreams. * **UNASSIGNED** * (none) People Present (lines said) --- * thozza (62) * sgallagh (36) * zodbot (12) * zbyszek (12) * number80 (11) * nirik (10) * simo (10) * rishi` (7) * paragan (7) * jkurik (3) * rishi (0) * ajax (0) * hguemar (0) * jwb (0) * dgilmore (0) Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Schedule for Wednesday's FESCo Meeting (2015-11-25)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-11-25 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = = New business = #topic #1500 Deactivate accounts that infra could not contact for 7 days. .fesco 1500 https://fedorahosted.org/fesco/ticket/1500 #topic #1501 F24 System Wide Change: Systemd package split .fesco 1501 https://fedorahosted.org/fesco/ticket/1501 #topic #1502 F24 System Wide Change: Systemd file triggers .fesco 1502 https://fedorahosted.org/fesco/ticket/1502 #topic #1503 F24 System Wide Change: GHC 7.10 .fesco 1503 https://fedorahosted.org/fesco/ticket/1503 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- 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: Fedora IPv6 testing and improvements - request for ideas
On 04.11.2015 15:22, Pavel Simerda wrote: > - Original Message - > > From: "Zdenek Kabelac" <zkabe...@redhat.com> > > To: "Development discussions related to Fedora" > > <devel@lists.fedoraproject.org> > > Sent: Wednesday, November 4, 2015 1:43:12 PM > > Subject: Re: Fedora IPv6 testing and improvements - request for ideas > > > > Dne 4.11.2015 v 13:24 Petr Spacek napsal(a): > >> On 3.11.2015 18:50, Moez Roy wrote: > >>> Hi Pavel Simerda, > >>> > >>> The IPv6 updates are breaking stuff (and probably increasing the > >>> attack surface): > >>> > >>> Bug 1231946 - unbound-anchor ignores net.ipv6.conf.all.disable_ipv6=1 > >>> in /etc/sysctl.conf > >>> https://bugzilla.redhat.com/show_bug.cgi?id=1231946 > >>> > >>> Bug 1251762 - dnssec-triggerd ignores net.ipv6.conf.all.disable_ipv6=1 > >>> in /etc/sysctl.conf > >>> https://bugzilla.redhat.com/show_bug.cgi?id=1251762 > >>> > >>> (maybe other software like avahi also don't remember right now) > >>> > >>> You can reproduce this by putting "ipv6.disable=1" in the kernel command > >>> line. > >>> > >>> Doing 'setsebool -P domain_kernel_load_modules 1' would reduce the > >>> security provided by SELinux so it is not an option. > >>> > >>> Would appreciate fixes please. Thanks. > >> > >> "ipv6.disable=1" or blacklisting ipv6 modules is going against contemporary > >> ways how network APIs. Many contemporary software projects are > >> using IPv6-enabled network calls by default because both IPv6 and IPv4 > >> share the same name space on the machine so you only need to listen on a > >> IPv6 port to accept both IPv4 and IPv6. > >> > >> Apparently this is not Fedora-specific in any way because ArchLinux says > >> the same: > >> https://wiki.archlinux.org/index.php/IPv6#Disable_IPv6 > >> > >> "net.ipv6.conf.all.disable_ipv6=1" is good enough and should not have > >> negative > >> side-effects of "ipv6.disable=1". > >> > >> Having said that, I'm proposing to close all issues caused by > >> "ipv6.disable=1" > >> as WONTFIX. > > > > Hi > > > > I strongly object against this idea. > > > > System needs to work in IPv4 environment and with kernel without IPv6 > > enabled. > > > > There is number of reasons for keeping this possibility enabled - e.g. > > I want to use older kernel for regression testing, I want to have disabled > > IPv6 stack for security reasons and lots of other... > > I'm not taking any side in this discussion and will mostly attempt to reflect > actual usage, i.e. most installations dual-stack, some installations with > IPv6 disabled, no installations with IPv4 disabled (due to kernel inability > to disable IPv4). > > > So please do not replace coder's inability > > The project is about IPv6 and dual-stack testing and improvements. Insulting > authors who didn't make their software work with ipv6.disabled=1 isn't > helpful. > > > to write correct code to handle dual socket interface > > In some cases software authors do not expect a situation when > `socket(family=AF_INET6)` fails but `socket(family=AF_INET)` > succeeds. It is indeed a very special situation that such a > basic thing in the system fails. > > And that is indeed a very special situation. On most installation > the `socket()` calls with correct arguments will never fail. And > the IPv4 variant won't fail in any case which creates an undue > assymetry. > > > with disabling usage of while Fedora on kernel with > > IPv6 disabled. > > > > I'm fine if the particular software package would be IPv6 only - as long > > as there is no IPv4-only user who cares - it's correct way. > > Whether a package is IPv6 only and whether a package works with > ipv6.disabled=1 are two distinct things that need to be tested > separately. On the other IPv6 only packages are a very rare > phenomenon. > > > Just do NOT make such package a core system dependency - it has to remain > > optional. > > I don't see any reason to make a distinction between a dual-stack package > with IPv4 and IPv6 functionality and two distinct packages, one IPv4 only, > the other IPv6 only in this respect. Either way you end up with features > required for both protocols. > > Anyway, are there any specific packages that are mandatory in Fedora or > might become so? I'd like to avoid discussions about something purely > hypothetical. With the default DNS resolver change Unbound and dnssec-trigger would be installed by default. > Cheers, > > Pavel > Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+2 (CEST) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Summary of Thursday's call between GNOME and NM devels and Default DNS resolver change owners
Hello all. I would like to share the outcome of the discussion between GNOME and NM developers and the Default DNS resolver [1] Change for F23. The full summary can be found here [2] and recording here [3] is anyone is interested. Integration points: - Captive portal detection - Captive portal handling - User interaction Points we agreed on: * Captive portal detecion * NM side * NM will be the only daemon doing Captive portal detection * NM moves connectivity check before NM_DEVICE_STATE_ACTIVATED, emits signal before network is up * If portal has been detected, NM blocks NM_DEVICE_STATE_ACTIVATED for a specific device until there is no more portal * NM regularly does the Captive portal detection (connectivity check) to determine if the login using GNOME was already done * Once the login was done and Internet connectivity is detected, NM triggers some event in nm-dispatcher (or something like that) * GNOME side * GNOME Shell does not do detection itself, but relies on the NM (as already done) * GNOME is watching the change of connectivity state property in NM * dnssec-trigger side * Does not do any detection * does not do any user interaction * Only relies on events triggered by NM and acts based on the connectivity status * Captive portal handling (login) * GNOME side * If Captive portal is detected, then browser window is launched * The browser window ls launched with LD_PRELOAD (https://github.com/hadess/resolvconf-override) as resolv.conf override * GNOME should fetch the connection-provided DNS servers using NM API (existing) and use those for LD_PRELOAD solution * dnssec-trigger side * does not do any user interaction * Only relies on events triggered by NM and acts based on the connectivity status * User interface / user interaction * Fedora Workstation product * GNOME shell * informs the user about the Captive portal * launches the window * dnssec-trigger * the applet will be split into separate package and not installed by default (already done) * if all falbacks fail, it switches automatically to Insecure mode (no DNSSEC validation) without user interaction * automatic switch to insecure mode will be possible to turn off using configuration file for expert users * a notification can be emited about switching to insecure mode (so far by default OFF) * Other desktops / Spins * dnssec-trigger applet * should handle the UI that is usually handled by GNOME Shell (if there is not any specific Spin implementation to do that, i.e. if GNOME is not in use) * Captive portal detection will be still done in NM * under discussion: * notification can be turned OFF by default, but configurable in config file for expert users - unfortunatelly this will not create pressure on admins to fix the networks * alternative: display a message which will say that local network is broken and that admin should be woken up: * 'Your network is seriously broken. Go and kick your network admin NOW! * This broken network will stop working from Fedora 24 on because it does not support DNSSEC. (Tell this to your admin!)' [1] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver [2] https://www.piratepad.ca/p/default-dns-resolver-f23 [3] https://bluejeans.com/s/8pTY/ Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: Summary/Minutes from today's FESCo Meeting (2015-07-01)
On 02.07.2015 17:56, Chris Murphy wrote: On Thu, Jul 2, 2015 at 9:45 AM, Stephen Gallagher sgall...@redhat.com wrote: On Thu, 2015-07-02 at 10:33 -0500, Michael Catanzaro wrote: On Thu, 2015-07-02 at 09:55 +0200, Tomas Hozza wrote: * AGREED: Netizen is not approved as spin. We approve the option to have netizen as optional suite in anaconda. Please work with Workstation WG. (+7, 0, -0) (thozza, 18:48:50) Hi, maybe there was some misunderstanding about the Workstation installer, but we don't allow configuration of package selection. Users are expected to use GNOME Software once the system is up and running. There were two combined statements there. The first was that we would consider making certain netizen-oriented options available at install -time. The second is that we would prefer to see tooling and configuration done inside the Workstation, KDE (and other?) environments rather than as a separate spin. The Workstation live installer doesn't have any installation options. The UI isn't even present in the installer. It's a single payload, all or nothing. It would have to be done as a group in GNOME Software. How is the Live installer different from the network installer? Is it just some configuration thing, or are those completely different installers? It looked like regular Anaconda last time I installed Workstation. I'm just trying to understand if you don't want to give the user the option to choose the installation options from live CD on purpose (due to user experience or such) or if there is some real issue? The Workstation network installer has installation options. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Summary/Minutes from today's FESCo Meeting (2015-07-01)
=== #fedora-meeting: FESCO (2015-07-01) === Meeting started by thozza at 18:01:35 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-07-01/fesco.2015-07-01-18.01.log.html . Meeting summary --- * init process (thozza, 18:01:36) * #1450 F23 System Wide Change: Python 3 as the Default Implementation (thozza, 18:05:02) * AGREED: let's make python3 the only python interpreter on default installs (+5, 0, -1) (thozza, 18:27:02) * Supplementary proposal to treat python2-only work as a bug in the implementation had insufficient votes (+2, 0, -3) (sgallagh, 18:30:40) * #1445 F23 Self Contained Changes (thozza, 18:31:00) * AGREED: All self-contained changes are approved (except netizen spin and io.js which are discussed separately) (+5, 0, -1) (thozza, 18:38:38) * AGREED: Netizen is not approved as spin. We approve the option to have netizen as optional suite in anaconda. Please work with Workstation WG. (+7, 0, -0) (thozza, 18:48:50) * AGREED: io.js change: Let the owner consider replacing node.js completely and revisit next week. (+7, 0, -0) (thozza, 19:00:01) * #1451 F23 System Wide Change: SELinux policy store migration (thozza, 19:00:21) * AGREED: F23 System Wide Change: SELinux policy store migration is approved (+5, 0, -0) (thozza, 19:05:55) * #1452 F23 System Wide Change: Two Week Atomic (thozza, 19:06:12) * AGREED: F23 System Wide Change: Two Week Atomic is approved (+6, 0, -0) (thozza, 19:10:30) * #1453 F23 System Wide Change: Glibc locale subpackaging (thozza, 19:10:43) * AGREED: F23 System Wide Change: Glibc locale subpackaging is approved. Please be careful with upgrade path. (+6, 0, -0) (thozza, 19:16:17) * #1454 F23 System Wide Change: Unicode 8.0 support (thozza, 19:16:36) * AGREED: F23 System Wide Change: Unicode 8.0 support is approved (+6, 0, -0) (thozza, 19:18:43) * #1455 F23 System Wide Change: Standardized Passphrase Policy (thozza, 19:18:58) * postponed until there is some concrete proposal (thozza, 19:19:17) * Next week's chair (thozza, 19:19:24) * paragan to chair next week (thozza, 19:22:13) * Open Floor (thozza, 19:22:26) Meeting ended at 19:30:09 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * thozza (171) * sgallagh (69) * ajax (54) * number80 (51) * jwb (50) * rishi` (31) * zodbot (20) * paragan (19) * rkuska (18) * cleong (15) * mstuchli (11) * mhroncok (7) * mgrepl (5) * plautrba (4) * jkurik (4) * mfabian (2) * maxamillion (2) * pravins (2) * mitr (1) * jkurik_mtg (1) * hguemar (0) * rishi (0) * nirik (0) * dgilmore (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot On 30.06.2015 12:02, Tomas Hozza wrote: Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-07-01 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1450 F23 System Wide Change: Python 3 as the Default Implementation .fesco 1450 https://fedorahosted.org/fesco/ticket/1450 #topic #1445 F23 Self Contained Changes .fesco 1445 https://fedorahosted.org/fesco/ticket/1445 = New business = #topic #1451 F23 System Wide Change: SELinux policy store migration .fesco 1451 https://fedorahosted.org/fesco/ticket/1451 #topic #1452 F23 System Wide Change: Two Week Atomic .fesco 1452 https://fedorahosted.org/fesco/ticket/1452 #topic #1453 F23 System Wide Change: Glibc locale subpackaging .fesco 1453 https://fedorahosted.org/fesco/ticket/1453 #topic #1454 F23 System Wide Change: Unicode 8.0 support .fesco 1454 https://fedorahosted.org/fesco/ticket/1454 #topic #1455 F23 System Wide Change: Standardized Passphrase Policy .fesco 1455 https://fedorahosted.org/fesco/ticket/1455 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 13:46, Stef Walter wrote: On 30.06.2015 11:24, Tomas Hozza wrote: On 26.06.2015 17:13, Matthias Clasen wrote: On Tue, 2015-06-23 at 18:43 +0200, Tomas Hozza wrote: Hey, I was out for a week, so this may be a bit of a late reply. As Michael and Bastien already stated, all the GNOME networking UI relies on information gotten from NetworkManager, and we'd like to keep it that way. In particular, NetworkManager has an existing API to inform us about captive portals - if at all possible, you should keep that working. Yes, it should work. We didn't change anything related to that. We just had our own implementation. [...] This boils down to what we need from some new version of the UI that we need to be well integrated with GNOME: 1. Be able to inform user about some situations (Captive portal detected, network blocks all DNS communication, ...) and enable the user to take an action. (This could be possibly done by the notifications system in latest GNOME) - this may be solved also in GNOME already, and may be OK if done technically correctly. Please note my note earlier on NM notifying other services when Captive Portal is detected My perspective on this is that we already have a UI: GNOME shell displays network status, including captive portal. If NetworkManager needs to add a few more connection states related to DNSSEC, we can adapt to that. The thing is that some information are unrelated to NM. There is no reason to push all information back to NetworkManager, since its role is explicitly defined - manage network connections and leave the DNS resolution and configuration up to different tool. GNOME shell also launches a browser when needed for captive portal login. If we need to tweak the way the browser is launched to make it work on a dnssec-enabled system, that should be possible. I was not able to determine if you rely on the system's stub resolver. If that is the case, NM should notify GNOME only after dnssec-trigger switches to hotspot signon mode. 2. Possibly have some indicator showing if the system is in Secure or Insecure state. 3. Enable the user to switch between those two states manually This seems dubious, at best. What does it mean if my system is 'insecure' ? Will my credit card number be stolen ? Will my system be taken over by intruders if I don't disconnect immediately ? Most users will have no idea, and have to treat such a switch either as scary, don't touch or as the fix the internet button. It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Stef Right. I just tried to explain what insecure means in this context. I agree that insecure is so generic, that it is hard or even impossible to explain. Maybe something like use plain DNS vs. DNSSEC enabled is better. But even the existing hotspot signon mode is OK. It was just an idea, it is really the lowest priority issue, to rename the mode... Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 13:58, Stef Walter wrote: On 30.06.2015 13:53, Bastien Nocera wrote: - Original Message - On 30.06.2015 11:24, Tomas Hozza wrote: snip It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Which means that it needs to be opt-in for us not to have unbreak my Internet buttons in the UI. Once DNSSEC is more widely deployed and we can safely assume that the majority of the Internet is used it, we can toggle it on. Yeah, that's one option. No, it is not. It is opt-in now, we want it by default. Please read the change. Thank you. Another is if dnssec-trigger can reliably detect the presence of DNSSEC on a given network, then it could enforce its use from then on. Except that this is exactly what we DON'T want to do. DNSSEC is an extension of DNS and it can be used even without the need for the whole Internet to be signed. We want to use it even if the network-provided DNS resolvers don't support DNSSEC. But making the user decide (or showing them a message) every time they connect to such networks is not the way to go. Nobody ever said that we want to do that. This is exactly what we DON'T want to do. Stef Tomas -- 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: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 13:53, Bastien Nocera wrote: - Original Message - On 30.06.2015 11:24, Tomas Hozza wrote: snip It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Which means that it needs to be opt-in for us not to have unbreak my Internet buttons in the UI. Once DNSSEC is more widely deployed and we can safely assume that the majority of the Internet is used it, we can toggle it on. This argument is not valid. DNSSEC is usable even without being deployed everywhere. You are welcomed to turn the functionality off if you don't care about security, we would like to turn DNSSEC validation by default and are trying to find common ground to make it possible. Tomas -- 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: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 14:11, Bastien Nocera wrote: - Original Message - On 30.06.2015 13:53, Bastien Nocera wrote: - Original Message - On 30.06.2015 11:24, Tomas Hozza wrote: snip It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Which means that it needs to be opt-in for us not to have unbreak my Internet buttons in the UI. Once DNSSEC is more widely deployed and we can safely assume that the majority of the Internet is used it, we can toggle it on. Yeah, that's one option. Another is if dnssec-trigger can reliably detect the presence of DNSSEC on a given network, then it could enforce its use from then on. The good thing being that NetworkManager knows all that, and that the desktop doesn't need to track which network we connected to, and whether or not it used DNSSEC. I would not like GNOME to track anything network related. I think NM is good place for tracking network configuration. We don't want GNOME to track anything, but rather to provide UI for tools that are tracking the state. But making the user decide (or showing them a message) every time they connect to such networks is not the way to go. Exactly, cf. which firewall zone is this network in discussions of yesteryear. I don't think we are interested in such discussion, since we don't think it is a good idea to expect regular users to do security related decisions. Tomas -- 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: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 14:37, Bastien Nocera wrote: - Original Message - snip No, it is not. It is opt-in now, we want it by default. Please read the change. Thank you. I don't see any options about it in GNOME's Network panel. I'm not interested in integration as an after-thought. This is exactly what this email thread is all about... integration. I think it best to stop this dead-end discussion until you've integrated DNSSEC support into NetworkManager. I'm open to discussion. I don't have problem with you not continuing it. Tomas -- 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: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 16:07, Michael Catanzaro wrote: On Tue, 2015-06-30 at 11:24 +0200, Tomas Hozza wrote: The thing is that some information are unrelated to NM. There is no reason to push all information back to NetworkManager, since its role is explicitly defined - manage network connections and leave the DNS resolution and configuration up to different tool. I'm not sure I agree with that, from a desktop developer perspective. It's very convenient for GNOME (and probably also KDE) for NetworkManager to be the one-stop shop for network management. It already allows you to configure DNS anyway (in GNOME, under Network - hidden gear menu in the lower right - IPv4 or IPv6) so there has to be some level of integration to keep that working. This will still work. We are not going to interfere with the configuration that NM stores. If you configured explicit DNS servers, dnssec-trigger will still try to use those. However if they don't support DNSSEC, it will fallback to some other method. If by configuring DNS you mean writing content into resolv.conf, then NM will not do that any more. Instead we will use configuration from NM, including the user defined values. We will test the DNS servers and act upon the results of tests. There is a draft of the final configuration based on the network configuration [1]. Note that we don't care if the DNS servers came from DHCP or if user specified these manually. We act only on the final config provided by NM. [1] https://fedoraproject.org/w/index.php?title=Networking/NameResolution/DNSSEC/UnboundMixedMode#Usage Regards, Tomas -- 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: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 16:07, Michael Catanzaro wrote: On Tue, 2015-06-30 at 14:23 +0200, Tomas Hozza wrote: Except that this is exactly what we DON'T want to do. DNSSEC is an extension of DNS and it can be used even without the need for the whole Internet to be signed. We want to use it even if the network-provided DNS resolvers don't support DNSSEC. I'm confused on one point: why would the user ever want to turn off DNSSEC validation (except to get past a for captive portal)? It sounds like you have no shortage of safeguards in place to make sure this always works: for it to break the user would have to be on a network that doesn't support DNSSEC, that blocks VPN, with the Fedora infrastructure down, right? I think it's OK to fail connections in that case (provided we have a story for captive portals). What we basically do not want is to give the user an option for turning a security feature off. Thank you for explanation. In that case we don't need any UI integration for this. Even though we use dnssec-trigger daily on our machines, we wanted to give the user a way to disable the feature if needed without the root access. This is more of a precaution in case something is broken and we didn't know about it. Tomas -- 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: DNSSEC/unbound - boingboing.net failures
On 30.06.2015 17:07, Matthew Miller wrote: With the DNSSEC feature enabled as per the testing instructions, I'm sometimes (but not always) getting failures for popular geek blog Boing Boing, when public DNS still works: $ host boingboing.net Host boingboing.net not found: 2(SERVFAIL) $ host boingboing.net 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: boingboing.net is an alias for boingboing.net.global.prod.fastly.net. boingboing.net.global.prod.fastly.net is an alias for global-ssl.fastly.net. global-ssl.fastly.net is an alias for fallback.global-ssl.fastly.net. fallback.global-ssl.fastly.net has address 199.27.76.249 fallback.global-ssl.fastly.net has address 23.235.46.249 What's going on here? How can I diagnose it, and how can we fix it so that users don't have to diagnose these situations? I'm concerned that if it's happening with this site (which Alexa rates as in the top 1000 websites in the US), it'll happen with a lot of others. Hi Matt. Please file a bug against dnssec-trigger. It will be better for getting additional information. Also please see the reply by Paul Wouters to your previous email. Thanks in advance. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2015-07-01)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-07-01 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1450 F23 System Wide Change: Python 3 as the Default Implementation .fesco 1450 https://fedorahosted.org/fesco/ticket/1450 #topic #1445 F23 Self Contained Changes .fesco 1445 https://fedorahosted.org/fesco/ticket/1445 = New business = #topic #1451 F23 System Wide Change: SELinux policy store migration .fesco 1451 https://fedorahosted.org/fesco/ticket/1451 #topic #1452 F23 System Wide Change: Two Week Atomic .fesco 1452 https://fedorahosted.org/fesco/ticket/1452 #topic #1453 F23 System Wide Change: Glibc locale subpackaging .fesco 1453 https://fedorahosted.org/fesco/ticket/1453 #topic #1454 F23 System Wide Change: Unicode 8.0 support .fesco 1454 https://fedorahosted.org/fesco/ticket/1454 #topic #1455 F23 System Wide Change: Standardized Passphrase Policy .fesco 1455 https://fedorahosted.org/fesco/ticket/1455 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- 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: dnssec-trigger + GNOME + NetworkManager integration
On 26.06.2015 17:13, Matthias Clasen wrote: On Tue, 2015-06-23 at 18:43 +0200, Tomas Hozza wrote: Hey, I was out for a week, so this may be a bit of a late reply. As Michael and Bastien already stated, all the GNOME networking UI relies on information gotten from NetworkManager, and we'd like to keep it that way. In particular, NetworkManager has an existing API to inform us about captive portals - if at all possible, you should keep that working. Yes, it should work. We didn't change anything related to that. We just had our own implementation. [...] This boils down to what we need from some new version of the UI that we need to be well integrated with GNOME: 1. Be able to inform user about some situations (Captive portal detected, network blocks all DNS communication, ...) and enable the user to take an action. (This could be possibly done by the notifications system in latest GNOME) - this may be solved also in GNOME already, and may be OK if done technically correctly. Please note my note earlier on NM notifying other services when Captive Portal is detected My perspective on this is that we already have a UI: GNOME shell displays network status, including captive portal. If NetworkManager needs to add a few more connection states related to DNSSEC, we can adapt to that. The thing is that some information are unrelated to NM. There is no reason to push all information back to NetworkManager, since its role is explicitly defined - manage network connections and leave the DNS resolution and configuration up to different tool. GNOME shell also launches a browser when needed for captive portal login. If we need to tweak the way the browser is launched to make it work on a dnssec-enabled system, that should be possible. I was not able to determine if you rely on the system's stub resolver. If that is the case, NM should notify GNOME only after dnssec-trigger switches to hotspot signon mode. 2. Possibly have some indicator showing if the system is in Secure or Insecure state. 3. Enable the user to switch between those two states manually This seems dubious, at best. What does it mean if my system is 'insecure' ? Will my credit card number be stolen ? Will my system be taken over by intruders if I don't disconnect immediately ? Most users will have no idea, and have to treat such a switch either as scary, don't touch or as the fix the internet button. It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. I could see adding information regarding the dnssec status of connections to the network panel. For that to happen, the information needs to be represented in the nm connection configuration, e.g. in NmSettingIP4Config, which already has settings like ignore-auto-dns. We can determine if the connection provided DNS resolvers are usable for DNSSEC validation, but that's it. There is no such thing as secure connection from DNS/DNSSEC point of view. The DNS resolvers for global name resolution are always taken from the default connection (if these are able to provide DNSSEC data) or full recursion is used or Fedora fallback infrastructure is used. Then for VPNs explicit forward zones are configured, with VPN provided DNS resolvers. So the bottom line is, that it does not make sense to distinguish security status of a connection from DNS/DNSSEC point of view, but rather the security status of the whole system and DNS resolution as a service provided by the system via stub resolver. 4. Additionally enable the user to trigger the reprobe of connection-provided DNS resolvers and display result of the probe (last one). - this should not be needed for regular use. It is more of a debugging tool I would encourage you to ship it separately as such, then. I don't even think it needs to be a graphical tool, a commandline utility would be just fine for this purpose. There is already a commandline tool that does all the things the GTK panel does. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: Schedule for Wednesday's FESCo Meeting (2015-06-24)
=== #fedora-meeting: FESCO (2015-06-24) === Meeting started by thozza at 18:00:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-06-24/fesco.2015-06-24-18.00.log.html . Meeting summary --- * init process (thozza, 18:00:02) * No quorum today. The meting is canceled. See you next week. (thozza, 18:10:14) Meeting ended at 18:10:14 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * thozza (13) * nirik (6) * zodbot (6) * mstuchli (5) * mhroncok (5) * rkuska (4) * jwb (3) * jkurik (2) * mitr (1) * mgrepl (1) * sgallagh (0) * rishi (0) * paragan (0) * ajax (0) * dgilmore (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot On 23.06.2015 17:43, Tomas Hozza wrote: Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-06-24 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1450 F23 System Wide Change: Python 3 as the Default Implementation .fesco 1450 https://fedorahosted.org/fesco/ticket/1450 #topic #1445 F23 Self Contained ChangesImplementation .fesco 1445 https://fedorahosted.org/fesco/ticket/1445 = New business = #topic #1451 F23 System Wide Change: SELinux policy store migration .fesco 1451 https://fedorahosted.org/fesco/ticket/1451 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2015-06-24)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-06-24 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1450 F23 System Wide Change: Python 3 as the Default Implementation .fesco 1450 https://fedorahosted.org/fesco/ticket/1450 #topic #1445 F23 Self Contained ChangesImplementation .fesco 1445 https://fedorahosted.org/fesco/ticket/1445 = New business = #topic #1451 F23 System Wide Change: SELinux policy store migration .fesco 1451 https://fedorahosted.org/fesco/ticket/1451 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
dnssec-trigger + GNOME + NetworkManager integration
://www.nlnetlabs.nl/projects/dnssec-trigger/#screenshots I'm all for simple and clean integration. Let's identify specific solutions and pieces we can start working on. Thanks. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: F23 System Wide Change: Default Local DNS Resolver
On 18.06.2015 13:14, Bastien Nocera wrote: - Original Message - On 12.06.2015 19:00, Matthew Miller wrote: On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote: Yeah, we did. From my recollection, most of that focused on the unbound parts and how NM could add the dns=unbound stuff (which Pavel contributed) but less on the NM connectivity checking, becuase Fedora hadn't turned that on by default yet. I'm all fine with dns=unbound, that's not the issue. The issue is more around what happens with NM's connectivity checking, since that's used by quite a few clients, including GNOME Shell. I personally find the anchor icon very confusing. As a non-expert in this area, it doesn't represent anything which seems relevant to me, and all of the right click menu options, once I figured out to right click, are obscure to me. I plan to contact the GNOME folks about how they would be willing to better integrate the panel (most probably in a different form) into GNOME. I don't think we want to integrate one more panel applet. The information about the DNS security should be passed on from NetworkManager. Once that's figured out, we can discuss how to show that information. I think you should discuss with us the approach before saying that you don't want to integrate with dnssec-trigger. We don't see any reason why the information should be passed back to NM. The information can be passed or gathered from dnssec-trigger itself. We don't want to lock ourselves only to NetworkManager, since there are also other network configuration managers. The code needs to integrate with various NetworkManager features, such as VPNs and connectivity checking. Adding any UI for network information provided via a side-channel would be premature. VPNs... done like 2 years ago. From what we discussed the connectivity checking is not really perfect in NM, since it assumes that DHCP provided resolvers are in resolv.conf because NM obviously uses system's stub resolver. If there are any valid integration pieces, please be specific. I would love to see more will for cooperation from GNOME people, so we can converge to the working and well integrated solution. Vague claims that something is missing or something needs to be done, without clear reasoning is not helping anyone. Cheers -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: F23 System Wide Change: Default Local DNS Resolver
On 17.06.2015 16:22, Paul Wouters wrote: On Wed, 17 Jun 2015, Tomas Hozza wrote: While I don't actually care, this might well be a sticking point for many people since their DNS information is going to an untrusted (to them) DNS server. Yeah, I tend to trust Fedora, but not everyone will. If you don't trust fedora infrastructure, you have more issues though Can the tunnel be turned off, or the broken servers whitelisted, or is the answer here to just dnf remove dnssec-trigger? Yes. It is all configured in /etc/dnssec-trigger/dnssec-triggerd.conf The fallback infrastructure is used as the last resort of DNS data source. Full recursion is preferred over the fallback servers. And full recursion means your privacy might be in even more danger too until the IETF dprive comes up with DNS privacy protocols. If someone is trusting a DNS server without using DNSSEC, that that person is not really aware of the potential security implications of such name resolution. With DNSSEC validation done locally, it is irrelevant what DNS servers are uses, as long they can provide all the DNSSEC data. I think DNS privacy was the issue here, not security. Eg the fact that fedora servers see your DNS queries for evil.com. There are no logs kept of queries to these servers. I think we would discontinue the service before adding logging to them. It is not like Fedora infrastructure is collecting data about which user is resolving which name. Although ANY DNS service provider can do that! If user wants to use broken nameservers, they can switch the dnssec-trigger to hotspot sign-on mode. I agree that this is completely not intuitive and should be rather named insecure mode. Practically this means that the DHCP provided resolvers are placed into resolv.conf and the user is free to shoot themselves into the feet. And your VPN DNS forwards are no longer used, so if you have a VPN up, then going into insecure mode means your network behind the VPN becomes basically unreachable. The hotspot/insecure mode is not a dont trust fedora mode. People should not use that way. Right, although it would be technically possible to also add VPN resolvers to resolv.conf in hotspot signon mode it is not the goal of the mode. Also turning off the dnssec-triggerd.service is a solution, since it will clean up after itself and return back the system to the original state. Of course you can remove it if you wish :) But that would affect all users. Granted, we are probably talking about private laptops here. But in theory one should disable dnssec-trigger-panel on a per-user basis, and not stop the system service. Right, I meant it for the single-user machine. Disabling the panel will not turn off the dnssec-trigger itself, so I don't think it would solve anything other than getting rid of the UI popup windows. systemd-resolved plans to do just a kind of best effort DNSSEC, at least from what I asked on the Linux PLumbers Conference in Dusseldorf last year on the Tom Gundersen's presentation. This means they will do the validation, but only if they are able to. They don't plan and don't want to do any fallback to external infrastructure, but rather want to turn off the validation. I'm not sure if this is still the case, but it was. This is exactly what we don't want to do with dnssec-trigger and Unbound. We will try really hard to do DNSSEC validation. A design that will just turn it off DNSSEC, possibly even silenly, seems like the wrong approach. I assume we are misunderstanding the systemd-resolvd goals here, and will let the systemd people explain their design. I hope, too. :) If this is indeed what you're proposing, then lets have a discussion about dnssec-trigger+unbound in that context, I do have some thoughts to contribute here. Good, we are open to thoughts and ideas ;) Indeed, I'm curious to what others have to say. Clearly, I have a somewhat strong bias toward DNSSEC :) Paul Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: F23 System Wide Change: Default Local DNS Resolver
On 12.06.2015 19:17, Paul Wouters wrote: On 06/12/2015 12:53 PM, Dan Williams wrote: b) Broken networks: Some networks are so broken that even without captive portal they are not able to deliver DNSSEC data to the clients. In that case will try tunnel to other DNS servers on the Internet (Fedora Infra or public DNS root) and use them. Naturally, local/internal domains need to be available. While I don't actually care, this might well be a sticking point for many people since their DNS information is going to an untrusted (to them) DNS server. Yeah, I tend to trust Fedora, but not everyone will. Can the tunnel be turned off, or the broken servers whitelisted, or is the answer here to just dnf remove dnssec-trigger? The fallbacks are configured in /etc/dnssec-trigger/dnssec-triggerd.conf # Provided by fedoraproject.org, #fedora-admin # It is provided on a best effort basis, with no service guarantee. ssl443: 140.211.169.201 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2 tcp80: 140.211.169.201 ssl443: 66.35.62.163 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2 tcp80: 66.35.62.163 ssl443: 152.19.134.150 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2 tcp80: 152.19.134.150 ssl443: 2610:28:3090:3001:dead:beef:cafe:fed9 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64 :AA:87:E6:F2 tcp80: 2610:28:3090:3001:dead:beef:cafe:fed9 Can we integrate on one place (e.g. by calling into dnssec-trigger) instead overwriting /etc/resolv.conf independently? This is the real issue. It sounds like What you're proposing is to make dnssec-trigger into the DNS broker. The previous solutions (resolvconf, NetworkManager, etc) have all failed for various reasons. Touching/changing something so fundamental to the system, as you've probably discovered, can be hard... But it must be done for security reasons. systemd-resolved might have a chance here, since it's small and pretty simple, but they don't have an external API and don't seem interested in creating one any time soon which severely limits it's usefulness. And last I looked it did not support DNSSEC. I'm also weary about systemd-resolved basically marshalling DNS via DBUS. If this is indeed what you're proposing, then lets have a discussion about dnssec-trigger+unbound in that context, I do have some thoughts to contribute here. I believe we selected dnssec-trigger because it was the UI/daemon that worked. A better native integration into either NM or Gnome would be preferred. I had the same idea before, but given that there is not only NM, but also other projects that intend to do the same thing as NM and even replace it in some environments (e.g. systemd-networkd) I don't think it makes sense to implement the same thing in each and every of these. I changed my mind and think that having one component implementing the functionality and communicating with the network configuration software that is used on the specific platform is a better approach. Although dnssec-trigger may not be ideal as final solution, it is a good for start and as a proof of concept of how to do client side DNSSEC validation properly. Tomas Paul -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: F23 System Wide Change: Default Local DNS Resolver
On 12.06.2015 18:58, Dan Williams wrote: On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote: On 11.06.2015 22:48, Dan Williams wrote: On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote: On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote: decision needs to then be made by the system. I believe that's been mostly due to lack of time for the various parties to sit down and plan and then program this further. We should try to make that happen. Unfortunately the Proposal doesn't say anything about how this will actually work, which is something NetworkManager needs to know. It also fails to address the failure cases where your local DNS doesn't support DNSSEC or is otherwise broken here out of no fault of your own. NetworkManager is pure network configuration manager in this scenario. We don't expect nor want NM to handle /etc/resolv.conf. We will only get the current network configuration from it and act upon it. NM configuration will contain dns=unbound. Correct, and I personally have no problem with this. NM is quite happy to hand off DNS information wherever it has been told to do so. But this is separate from the connectivity detection/hotspot issue which I think we'll discuss more below. The cases when local (to the network you are connected to) DNS resolver does not support DNSSEC is handled by the logic in dnssec-trigger and dnssec-trigger script. Unbound is always configured in a way that it is able to do DNS resolution and DNSSEC validation. If this can not be done, the user is informed. Right, and that's where most of this discussion lies, I think. I see that there's a hotspot sign on option if you right click on the icon. How does this work with Network Manager and GNOME's captive portal detection? I have never seen those work except for when the backend was down and I got a stream of false positives. But possibly that is because I've used dnssec-trigger for years now and it might win the captive portal detection race. There are some bugs once in a while but overal it works pretty reliably. I think that's probably it — the race. The hotspot signon thing works for me at coffeeshops. Or it did before I enabled this feature. We'll see now! So, if you're behind a portal then unbound could potentially fail all DNS lookups. That means that NetworkManager's connectivity detection, which relies on retrieving a URL from a known website, will fail because the DNS lookup for it was blocked by unbound. Thus GNOME Shell portal detection will also fail. That kinda sucks. If there is such situation, that Unbound fails all DNS lookups, then it is a bug. This is pure theory until you have some real situation. The logic is designed in a way to prevent such situations from ever happen. Hotspot detection is done by dnssec-trigger. The hot-spot-signon is done by putting DHCP provided resolvers into resolv.conf. So in this situation Unbound it not used at all. While I'm sure the dnssec-trigger panel applet works great for some people, I think the GNOME team would rather have the portal functionality in the existing GNOME Shell indicator. There is nothing wrong with having DNSSEC enabled and part of the portal detection scheme, but the UI handling portals is clearly a desktop-specific decision. So whatever we need to do in NM to enable the workflow that desktops need is what we'll end up doing... Ideally the process goes like this when unbound/dnssec-trigger are installed: 1. NM connects to a new network 1.1. Dispatch dispatcher with the network configuration change event. 2. NM updates DNS information NM is not expected to touch resolv.conf in the intended default configuration. My #2 was intended to be the same as your #1.1. I was assuming dns=unbound here. 3. NM waits for some signal from unbound/dnssec-trigger about the trustability of the DNS server If you think NM needs to do some action (as I don't), we don't have problem with notifying NM (if you provide some API). NM may need to do some action for connectivity checking. 3a. if the DNS server is trusted, NM continues with its connectivity check 3b. if the DNS server is not trusted or DNSSEC is broken, then ??? How do we distinguish between portal and simply that your local DNS doesn't support DNSSEC or is otherwise broken, if we cannot resolve the address of the connectivity server? The only trusted DNS resolver is the local Unbound. The DNS resolver from the network you are connected to is never trusted. It is just used in case it can provide all the necessary information to do the DNSSEC validation. Since using such data we are able to build the chain of trust and verify that the Answer is correct, there is no point in distinguishing if network provided resolver is trusted or not... it is not. This is the reason we do the validation locally. Ok, I should rephrase my question to be clearer. NM's connectivity checking
Re: Packaging Guidelines for Applications using Git Submodules
On 13.06.2015 04:33, Gerald B. Cox wrote: I'm trying to figure out the best way to handle the situation where a project decides to use submodules in Git. The archive generated doesn't incorporate the submodule files. I've done some searching on this, and haven't really come up with much. I've reviewed: Packaging:Github https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#Github ; but that really doesn't address the submodule issue. I looked through some packages that are currently in the Fedora repository and found where a few folks have rebuilt the tarball and referenced that version as the Source in the spec file; then they put in a comment stating: The source of this package was pulled from upstreams' vcs. Use the following commands to generate the tarball: ... - git clone ... - git submodule init - git submodule update ... This approach is the best that I've found. Any other suggestions? Thanks much! Hi. I think the approach used in the existing packages ~ to rebuild the source tarball is a valid solution. You may want to file a FPC ticket [1] describing the situation, so that FPC may potentially change the Packaging guidelines to include some note on git submodules. If you have some proposed draft of the change (e.g. describing the current approach used in other packages) I think it is a good idea to include it. [1] https://fedorahosted.org/fpc/ Regards, Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: F23 System Wide Change: Default Local DNS Resolver
On 12.06.2015 16:58, Paul Wouters wrote: On Fri, 12 Jun 2015, Matthew Miller wrote: Another integration concern: the network config GUI (and ifcfg files, for that matter) let me list specific DNS servers. With this feature, are those used (and if so, how)? If not, is my configuration just silently ignored? I do not know if it is supported currently, but support for that is very trivial. If unbound is found running, issue: unbound-control forward_add . 1.2.3.4 5.6.7.8 I'm not sure whose job that would be. Paul This should be ideally left to the network configuration software (e.g. NM). Dnssec-trigger will not touch any forward zones that are already configured in Unbound and it didn't configured them itself. While technically this should not be a problem, and everything should work properly (since forward zones are configured properly), this should be ideally done only by the dnssec-trigger based on the information passed by VPN to the NM. Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: F23 System Wide Change: Default Local DNS Resolver
On 12.06.2015 18:53, Dan Williams wrote: On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek wrote: On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote: On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote: decision needs to then be made by the system. I believe that's been mostly due to lack of time for the various parties to sit down and plan and then program this further. We should try to make that happen. Okay, let's start once again from scratch. All of this was already discussed and we even had a huge meeting around DevConf and FLOCK 2014 about this, so following text will be just a short refresher: Yeah, we did. From my recollection, most of that focused on the unbound parts and how NM could add the dns=unbound stuff (which Pavel contributed) but less on the NM connectivity checking, becuase Fedora hadn't turned that on by default yet. I'm all fine with dns=unbound, that's not the issue. The issue is more around what happens with NM's connectivity checking, since that's used by quite a few clients, including GNOME Shell. The ultimate goal = Make various man-in-the-middle attacks *automatically* detectable - without any user interaction. Especially we want to get rid of dialogs like Site www.gmail.com is using certificate issued for xxx.porn and certificate's validity ended 10 years ago. Do you want to continue? [YES] [YES] [YES]. Tools = To achieve this goal we need to do DNSSEC validation on every client machine (ignoring Docker for a moment, see below) and allow applications to use DNS as trusted source of sensitive data (certificate fingerprints, SSH fingerprints, etc.). DNSSEC allows all parties to publish their fingerprints in DNS and gives us a secure way to get the data and to detect that someone prevents us from getting the data. Longer description == http://developerblog.redhat.com/2015/04/14/writing-an-application-that-supports-dnssec-in-rhel-and-fedora/ First step: DNSSEC validation = Contemporary networks are full of broken DNS proxies so we need to jump through various hoops to get non-faked DNSSEC data for DNSSEC validation. The goal of this step is to get *cryptographical* proof that the data we received are the same as DNS zone owner published. This includes two sub-problems: a) Hot-spots: Captive portal detection needs to allow user to disable all the security so he can log-in but this needs to be done in a secure and reliable way so an attacker cannot misuse this. b) Broken networks: Some networks are so broken that even without captive portal they are not able to deliver DNSSEC data to the clients. In that case will try tunnel to other DNS servers on the Internet (Fedora Infra or public DNS root) and use them. Naturally, local/internal domains need to be available. While I don't actually care, this might well be a sticking point for many people since their DNS information is going to an untrusted (to them) DNS server. Yeah, I tend to trust Fedora, but not everyone will. Can the tunnel be turned off, or the broken servers whitelisted, or is the answer here to just dnf remove dnssec-trigger? The fallback infrastructure is used as the last resort of DNS data source. Full recursion is preferred over the fallback servers. If someone is trusting a DNS server without using DNSSEC, that that person is not really aware of the potential security implications of such name resolution. With DNSSEC validation done locally, it is irrelevant what DNS servers are uses, as long they can provide all the DNSSEC data. It is not like Fedora infrastructure is collecting data about which user is resolving which name. Although ANY DNS service provider can do that! If user wants to use broken nameservers, they can switch the dnssec-trigger to hotspot sign-on mode. I agree that this is completely not intuitive and should be rather named insecure mode. Practically this means that the DHCP provided resolvers are placed into resolv.conf and the user is free to shoot themselves into the feet. Also turning off the dnssec-triggerd.service is a solution, since it will clean up after itself and return back the system to the original state. Of course you can remove it if you wish :) All these sub-problems (including VPN handling an so on) are solved by dnssec-trigger with tweaks by Tomas Hozza and Pavel Simerda. HERE we need to coordinate with other parties who might want to write into the /etc/resolv.conf file. These include (but might not be limited to): NetworkManager initscripts dhclient libreswan ? resolved connman pppd, vpnc, openvpn, etc. should get added to the list since they all have scripts that can potentially write to /etc/resolv.conf. Option is either to implement all the checks and workarounds in all the projects over and over or to implement all the logic in one place - dnssec-trigger
Re: F23 System Wide Change: Default Local DNS Resolver
On 12.06.2015 19:00, Matthew Miller wrote: On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote: Yeah, we did. From my recollection, most of that focused on the unbound parts and how NM could add the dns=unbound stuff (which Pavel contributed) but less on the NM connectivity checking, becuase Fedora hadn't turned that on by default yet. I'm all fine with dns=unbound, that's not the issue. The issue is more around what happens with NM's connectivity checking, since that's used by quite a few clients, including GNOME Shell. I personally find the anchor icon very confusing. As a non-expert in this area, it doesn't represent anything which seems relevant to me, and all of the right click menu options, once I figured out to right click, are obscure to me. I plan to contact the GNOME folks about how they would be willing to better integrate the panel (most probably in a different form) into GNOME. I understand Hotspot sign-on and can go from there, but I can't see it not completely perplexing e.g. my dad. I agree that something like insecure mode would be more self-explanatory. I don't know what Reprobe does (and especially not because there's no context other than the anchor), and Probe Results give some indication that it has to do with DNSSEC — but I think that if our users have to learn what that means and understand all that in order to be secure (or just to browse the web at _any_ level), we're not succeeding. I hope we can get a design for this which integrates better with GNOME Shell and the existing network icon there. I hope too. Regards, Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: F23 System Wide Change: Default Local DNS Resolver
On 11.06.2015 22:48, Dan Williams wrote: On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote: On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote: decision needs to then be made by the system. I believe that's been mostly due to lack of time for the various parties to sit down and plan and then program this further. We should try to make that happen. Unfortunately the Proposal doesn't say anything about how this will actually work, which is something NetworkManager needs to know. It also fails to address the failure cases where your local DNS doesn't support DNSSEC or is otherwise broken here out of no fault of your own. NetworkManager is pure network configuration manager in this scenario. We don't expect nor want NM to handle /etc/resolv.conf. We will only get the current network configuration from it and act upon it. NM configuration will contain dns=unbound. The cases when local (to the network you are connected to) DNS resolver does not support DNSSEC is handled by the logic in dnssec-trigger and dnssec-trigger script. Unbound is always configured in a way that it is able to do DNS resolution and DNSSEC validation. If this can not be done, the user is informed. I see that there's a hotspot sign on option if you right click on the icon. How does this work with Network Manager and GNOME's captive portal detection? I have never seen those work except for when the backend was down and I got a stream of false positives. But possibly that is because I've used dnssec-trigger for years now and it might win the captive portal detection race. There are some bugs once in a while but overal it works pretty reliably. I think that's probably it — the race. The hotspot signon thing works for me at coffeeshops. Or it did before I enabled this feature. We'll see now! So, if you're behind a portal then unbound could potentially fail all DNS lookups. That means that NetworkManager's connectivity detection, which relies on retrieving a URL from a known website, will fail because the DNS lookup for it was blocked by unbound. Thus GNOME Shell portal detection will also fail. That kinda sucks. If there is such situation, that Unbound fails all DNS lookups, then it is a bug. This is pure theory until you have some real situation. The logic is designed in a way to prevent such situations from ever happen. Hotspot detection is done by dnssec-trigger. The hot-spot-signon is done by putting DHCP provided resolvers into resolv.conf. So in this situation Unbound it not used at all. While I'm sure the dnssec-trigger panel applet works great for some people, I think the GNOME team would rather have the portal functionality in the existing GNOME Shell indicator. There is nothing wrong with having DNSSEC enabled and part of the portal detection scheme, but the UI handling portals is clearly a desktop-specific decision. So whatever we need to do in NM to enable the workflow that desktops need is what we'll end up doing... Ideally the process goes like this when unbound/dnssec-trigger are installed: 1. NM connects to a new network 1.1. Dispatch dispatcher with the network configuration change event. 2. NM updates DNS information NM is not expected to touch resolv.conf in the intended default configuration. 3. NM waits for some signal from unbound/dnssec-trigger about the trustability of the DNS server If you think NM needs to do some action (as I don't), we don't have problem with notifying NM (if you provide some API). 3a. if the DNS server is trusted, NM continues with its connectivity check 3b. if the DNS server is not trusted or DNSSEC is broken, then ??? How do we distinguish between portal and simply that your local DNS doesn't support DNSSEC or is otherwise broken, if we cannot resolve the address of the connectivity server? The only trusted DNS resolver is the local Unbound. The DNS resolver from the network you are connected to is never trusted. It is just used in case it can provide all the necessary information to do the DNSSEC validation. Since using such data we are able to build the chain of trust and verify that the Answer is correct, there is no point in distinguishing if network provided resolver is trusted or not... it is not. This is the reason we do the validation locally. Dan I would like to add that this already works without any other interaction with NM. I agree that the notifications from dnssec-trigger are not ideal. I'm going to contact some GNOME guys and ask them for help. Thank you for your comments! Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: New ABRT CLI
On 06/02/2015 03:45 PM, Richard Marko wrote: Hi, over last two weeks I completely rewrote abrt-cli to make life easier for users and developers. It now supports tab completion and few new commands like abrt gdb and abrt debuginfo-install. Without any arguments these commands will use the last crash that occurred on your system. New cli is available in abrt-cli-ng subpackage and will replace old abrt-cli command in the future. Please help with testing according to instructions in the following copr: https://copr.fedoraproject.org/coprs/rmarko/abrt/ Feedback is highly appreciated. Thanks! One small thing. The install instructions are not completely correct. # dnf --disablerepo=* --enablerepo=rmarko-abrt install abrt-cli-ng Last metadata expiration check performed 0:00:16 ago on Wed Jun 3 08:02:55 2015. Error: nothing provides python-argcomplete needed by abrt-cli-ng-2.5.1-3.fc22.1.x86_64 So this needs to be installed without the --disablerepo=* argument. Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: F23 System Wide Change: Default Local DNS Resolver
On 06/02/2015 06:44 PM, Paul Wouters wrote: On Tue, 2 Jun 2015, David Howells wrote: Install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. The automatic name server entries received via dhcp/vpn/wireless configurations should be stored separately (e.g. this is stored in the NetworkManager internal state), as transitory name servers to be used by the trusted local resolver. In all cases, DNSSEC validation will be done locally. How does this interact with dnsmasq which also wants to be the only name server entry in resolv.conf? dnsmasq is not the default entry in /etc/resolv.conf. It can be used with NM, but unbound can be, too. dnsmasq was integrated with NM sooner, since it didn't have DNSSEC support, which made a lot of corner cases and issues basically non-existing. Unbound it relatively simple and single purpose DNS resolver that was designed with DNSSEC in mind from the beginning... in comparison to dnsmasq. dnsmasq is a Swiss knife that is good for simple solutions hacked together with single component (since it supports DHCPv4/6, TFPT and also DNS+DNSSEC). Not well? The problem is dnsmasq is not as feature complete as unbound (and its dnssec implementation is very new). I agree, and as a previous maintainer of dnsmasq, I think unbound is better option. Although dnsmasq has a simple DBus API, it is mostly for DHCP. Also unbound has modular design and easy interface (unbound-control) enabling to reconfigure it dynamically. I think most people end up running dnsmasq because of KVM/libvirtd ? I think those dnsmasq's should be run in dhcp only mode and point to the hosts's unbound. Right. dnsmasq run by libvirtd uses the default configuration WRT resolv.conf. So it uses the servers from resolv.conf for resolution - which will be unbound. There are not conflicts between unbound running as local resolver and dnsmasq instances run by libvirtd. Tomas -- 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: F23 System Wide Change: Default Local DNS Resolver
On 06/01/2015 03:32 PM, Matthew Miller wrote: On Mon, Jun 01, 2015 at 08:03:27AM -0400, Jan Kurik wrote: People use Fedora on portable/mobile devices which are connected to diverse networks as and when required. The automatic DNS configurations provided by these networks are never trustworthy for DNSSEC validation. As currently there is no way to establish such trust. Is this proposal meant to apply to Cloud and Server as well? With Cloud, it's at least conventional to assume that the network infrastructure provided by the provider is trustworthy (see cloud-init). And Server presumably will not be running on portable/mobile devices connecting to arbitrary networks. For Server, there may be other advantages, but do we also want these for Cloud? As you can read in the Change proposal, this is part of the scope: discuss with WGs in which products the change makes sense and what are the expectations of WGs for different Fedora products Yes, we think the change makes sense for Server. It is still beneficial from the security point of view to do the DNSSEC validation on Server. Even though the configuration on Server will be static, dnssec-trigger + unbound can be used for this. Otherwise it would require manual configuration from the administrator, to enable DNSSEC validation. As for the Cloud, we are not sure. Maybe it makes sense on the Atomic Host, but we want to discuss this with people involved in the Cloud product(s). I'm also concerned about going forward with this without having a solid answer to the container problem. This is also one of the scopes: resolve interoperability issues for Docker and other containers use-cases PJP is looking at this. This is work in progress. We will not enable the change in products and environments in which it will turn out that it does not make sense. Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Deprecation of ISC's DLV registry
Hi all. I received a heads-up from ISC that they are planning to deprecate their DLV registry (https://dlv.isc.org/) in the future. The use of ISC's DLV repository should be removed from any default configuration to prevent any issues in the future. I'm aware only about BIND and Unbound servers that use ISC's DLV in their default configuration in Fedora. If you are aware of any other component, please file a bug and add it to the tracking bug: https://bugzilla.redhat.com/show_bug.cgi?id=1223360 Thanks! Regards, Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: Schedule for Wednesday's FESCo Meeting (2015-03-11)
On 03/10/2015 04:06 PM, Tomas Hozza wrote: Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-03-11 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1412 anaconda password change is causing consternation among the user community please review this policy decision .fesco 1412 https://fedorahosted.org/fesco/ticket/1412 = New business = #topic #1420 policy change: admins (non-POC) should be able to retire packages .fesco 1420 https://fedorahosted.org/fesco/ticket/1420 #topic #1421 FESCO Decision on COPR/Playground in GNOME Software .fesco 1421 https://fedorahosted.org/fesco/ticket/1421 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. === #fedora-meeting: FESCO (2015-03-11) === Meeting started by thozza at 18:01:28 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-03-11/fesco.2015-03-11-18.01.log.html . Meeting summary --- * init process (thozza, 18:01:28) * #1412 anaconda password change is causing consternation among the user community please review this policy decision (thozza, 18:03:37) * LINK: http://pkgs.fedoraproject.org/cgit/anaconda.git/log/?h=f22 has last commit 7 days ago (mitr, 18:08:11) * ACTION: thozza to file a beta blocker bug for anaconda to get back to double-click for weak passwords (thozza, 18:12:39) * the proposal in the ticket is outdated since the alpha is already out. The change should go into beta. (thozza, 18:12:56) * ACTION: nirik to start a wiki page for discussion around the overall password policy (thozza, 18:15:36) * #1420 policy change: admins (non-POC) should be able to retire packages (thozza, 18:16:07) * AGREED: Allow also package admins to retire the package (+7, 0, -1) (thozza, 18:17:45) * #1421 FESCO Decision on COPR/Playground in GNOME Software (thozza, 18:18:07) * AGREED: FESCo agrees with changes proposed in https://fedorahosted.org/fesco/ticket/1421#comment:0 (+7, 0, -1) (thozza, 18:44:34) * Next week's chair (thozza, 18:44:50) * ACTION: sgallagh to update the Third_Party_Repos wiki page (sgallagh, 18:47:26) * nirik to chair next week's meeting (thozza, 18:47:43) * Open Floor (thozza, 18:47:52) * Password policy wiki page started at https://fedoraproject.org/wiki/User:Kevin/Draft_Passwordpolicy (thozza, 18:51:07) Meeting ended at 18:58:43 UTC. Action Items * thozza to file a beta blocker bug for anaconda to get back to double-click for weak passwords * nirik to start a wiki page for discussion around the overall password policy * sgallagh to update the Third_Party_Repos wiki page Action Items, by person --- * nirik * nirik to start a wiki page for discussion around the overall password policy * sgallagh * sgallagh to update the Third_Party_Repos wiki page * thozza * thozza to file a beta blocker bug for anaconda to get back to double-click for weak passwords * **UNASSIGNED** * (none) People Present (lines said) --- * thozza (66) * nirik (53) * sgallagh (45) * jwb (33) * mitr (21) * dgilmore (11) * ajax (8) * zodbot (7) * t8m (5) * Cydrobolt (3) * paragan (2) * rishi (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2015-03-11)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-03-11 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1412 anaconda password change is causing consternation among the user community please review this policy decision .fesco 1412 https://fedorahosted.org/fesco/ticket/1412 = New business = #topic #1420 policy change: admins (non-POC) should be able to retire packages .fesco 1420 https://fedorahosted.org/fesco/ticket/1420 #topic #1421 FESCO Decision on COPR/Playground in GNOME Software .fesco 1421 https://fedorahosted.org/fesco/ticket/1421 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- 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: FESCo elections are open
On 02/01/2015 10:39 AM, Alec Leamas wrote: On 30/01/15 16:10, Kevin Fenzi wrote: On Fri, 30 Jan 2015 15:58:00 +0100 Alec Leamas leamas.a...@gmail.com wrote: There were not really any questions directly related to products. Perhaps some could be added next time? In any case, I am in the Server working group myself, feel free to ask the other candidates. Fair enough. So, a question to all candidates: how are you related to the different products? Personally I'm not a member of any WG. However I maintain mostly server-related daemons, but not only... Tomas -- 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: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default
On 01/20/2015 01:08 PM, Tom Hughes wrote: On 20/01/15 11:53, Jaroslav Reznik wrote: * Other developers: ** Add /tmp-inst and /var/tmp/tmp-inst to filesystem. (packagename: filesystem) ** Enable namespaces in /etc/security/namespace.conf (packagename: PAM) ** Enable proper selinux context and polyinstantiation_enabled boolean to be set (packagename: selinux-policy-targeted or selinux-policy) So this effectively reverses tmp-on-tmpfs for users other than root and adm right? Because /tmp will actually be a subdirectory of /tmp-inst which will be a real directory? Why do you think this? I don't see any reason why the new tmp-inst directories can not be on tmpfs... Incidentally, why /tmp-inst but /var/tmp/tmp-inst? Why not /tmp/tmp-inst for /tmp or /var/tmp-inst for /var/tmp? Shouldn't the naming be consistent? Tom Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: F22 System Wide Change: Default Local DNS Resolver
On 01/19/2015 06:16 PM, Pete Zaitcev wrote: On Wed, 14 Jan 2015 06:26:49 +1030 William B will...@firstyear.id.au wrote: Right now, enabled unbound and dnssec-trigger on a laptop is an extremely difficult experience. Can you tell why you're trying that. Everyone I talk to always go unbound, unbound, unbound... WHY? Unbound is plain broken and does not work, especially with DNSSEC. But I use plain dnsmasq with NM, and everything works perfectly and fully automated by NM on my F21 laptop -- including VPN (with vpnc, no less), my internal LAN DNS, airports, office. Perhaps that's only because dnsmasq fails to participate in DNSSEC properly? Or what? Why is everyone so fixated on Unbound? -- Pete Unbound is designed to do one thing and do it right. To be used on client as default local resolver it needs something to configure it ~ dnssec-trigger. (e.g. dnsmasq is directly configured by NM) Unbound + dnssec-trigger + NM works just fine. Also with split DNS configuration. I use it every day at home, at work, with VPN. It works. I'm not saying there are any use-cases where it breaks, but those need to be identified and solved. Writing non-technical complains with zero information for developer in it will get us nowhere. People want to use unbound, because it does DNSSEC validation. dnsmasq had no DNSSEC implementation at the time there was already unbound and dnssec-trigger. If you use any resolver without DNSSEC the overall situation is a lot simpler. DNSSEC simply does not work with all the hacks people were doing with DNS before. As for unbound vs. dnsmasq... unbound does one thing - DNS validating resolver. While dnsmasq does almost everything (DNS resolver, validating resolver, DNS authoritative server, DHCPv4/DHCPv6 server, TFTP server) and has tons of hackish options. From this point of view, the choice is pretty clear I think. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: F22 System Wide Change: Default Local DNS Resolver
On 01/13/2015 08:56 PM, William B wrote: To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. snip ... People use Fedora on portable/mobile devices which are connected to diverse networks as and when required. The automatic DNS configurations provided by these networks are never trustworthy for DNSSEC validation. As currently there is no way to establish such trust. I have a number of concerns about the readiness of the proposal. Right now, enabled unbound and dnssec-trigger on a laptop is an extremely difficult experience. I have since taking up this challenge found that turn it off and on again, has become the default solution on my linux install now as a result of these problems. Personally I have completely different experience. I have unbound and dnssec-trigger on by default and it works at home, on WiFi, at work, with VPN... For example, crashes in unbound that are not caught in abrt, forwarders that do not get added (but they display in the list), queries that don't ever get replies (But they work when you by-pass unbound to your glibc forwarder), inability to flush dnscache without sudo, and that dns caches are held over network boundaries to name a few of my concerns. Did you file an issue to ABRT (or anywhere?) As for the cache, are you able to do that with dnsmasq? Without sudo you can't even change /etc/resolv.conf. I think we disagree on what should non-privileged user should be allowed to do. As a result, at this time, enabling this on your system is actually more of a deteriment that the benefit being touted. I would prefer working DNS over non working secure dns. (I guess it's secure because I can send any traffic out). Yes, without DNSSEC all the hackish network setups just work. Apart from trust, these name servers are often known to be flaky and unreliable. Which only adds to the overall bad and at times even frustrating user experience. In such a situation, having a trusted local DNS resolver not only makes sense but is in fact badly needed. It has become a need of the hour. (See: [1], [2], [3]) Unbound creates more flakiness than it solves. Unbound caches no answer as a negative cache entry. If your wireless blips for an instant, that's it, result vanishes. I think that there should be a large amount of QA focus on this change. Configurations involving split-view dns should be involved in testing, testing stability of unbound between suspend/resume, or even NetworkManager restarts, testing that quieries resolve in esoteric networks (IE networks that capture and redirect DNS traffic). We will be more than happy to receive any test cases and use-cases (with steps to setup) and use them for testing the readiness of the Change. However more than a relatively non-technical discussion about unclear use-cases that we are unable to reproduce due to insufficient information, we would welcome clear descriptions and clear statements describing what specifically is not working as it should. This is a change, that currently, has the potential to seriously damage the user experience of anyone using fedora. I think that much more rigorous testing and thought should go into this before we just steam ahead. If in it's current state you install unbound, you will begin to notice little issues quickly, especially on laptops. That is not a defalt we should aim for. We are willing to work on resolving user issues. If the change will be proven not ready, we are ready to work on issues and deffer it to F23. However from the past experience there is no way everyone will be happy with the changes, regardless of what those changes are. NOTE: I'm not just raging here, I actually have opened BZ's for these issues that I have. I think that awareness of these issues is low, and that it should be brought to light. I hope that more thorough testing is carried out in a wider set of environments to eventually get this to a point where it's a seamless change to enable this service. However at this time, that is not the case. We are thankful for your contributions in testing the setup. Hopefully you recognize some of the improvements done based on your reports. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: Bodhi policy for pushing updates to stable
On 01/15/2015 05:15 PM, Luke Macken wrote: On Thu, Jan 15, 2015 at 10:19:19AM +0100, Tomas Hozza wrote: Hi all. When upgrading F20 to F21 using FedUp, some users had a problem with some packages not being upgraded (e.g. [1]). The problem was caused by broken update path F20 - F21. For example in wget's case I pushed updates for the same NVR in F20 and F21 with auto-karma. However the wget update for F20 got the stable karma and was pushed to stable before the update for F21. I think bodhi should enforce the update path is not broken and hold the update for F20 until the update for F21 is in stable. I know I can do it manually and disable auto-karma and push updates to stable as they should be. However I think such task should be automated. Would it be possible to enforce such a thing for updates in bodhi? The broken upgrade path for the F20 wget update was detected by Taskotron[0], and then bodhi immediately disabled autokarma[1]. However, the stable karma threshold was reached about 5 minutes before it was detected, so it went out anyway. Bodhi2 already has Taskotron-based gating baked into the push process[2], but this specific issue can also be fixed in the current bodhi1 codebase. Upon Taskotron failure, if the update has already reached the stable karma threshold, bodhi should revoke the stable request. I opened an upstream ticket to track this issue[3] luke [0]: https://admin.fedoraproject.org/updates/FEDORA-2014-17194/wget-1.16.1-2.fc20 [1]: https://fedorahosted.org/fesco/ticket/1242 https://github.com/fedora-infra/bodhi/pull/41 [2]: https://github.com/fedora-infra/bodhi/pull/109 [3]: https://github.com/fedora-infra/bodhi/issues/116 Thank you for creating the ticket. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
BIND 9.10 in rawhide
Hi all. I updated BIND to the latest stable 9.10 version in rawhide, as discussed here [1]. Feel free to try it out. [1] https://fedoraproject.org/wiki/Changes/BIND_9.10 Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Bodhi policy for pushing updates to stable
Hi all. When upgrading F20 to F21 using FedUp, some users had a problem with some packages not being upgraded (e.g. [1]). The problem was caused by broken update path F20 - F21. For example in wget's case I pushed updates for the same NVR in F20 and F21 with auto-karma. However the wget update for F20 got the stable karma and was pushed to stable before the update for F21. I think bodhi should enforce the update path is not broken and hold the update for F20 until the update for F21 is in stable. I know I can do it manually and disable auto-karma and push updates to stable as they should be. However I think such task should be automated. Would it be possible to enforce such a thing for updates in bodhi? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1176403 Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: Schedule for Wednesday's FESCo Meeting (2014-12-10)
On 12/09/2014 07:22 PM, Tomas Hozza wrote: Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-12-10 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1349 Fedora 22 scheduling strategy (and beyond) .fesco 1349 https://fedorahosted.org/fesco/ticket/1349 = New business = #topic #1370 requesting exception for linking include-what-you-use with llvm-static .fesco 1370 https://fedorahosted.org/fesco/ticket/1370 #topic #1371 Nonresponsive maintainer: clockfor .fesco 1371 https://fedorahosted.org/fesco/ticket/1371 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. === #fedora-meeting: FESCO (2014-12-10) === Meeting started by thozza at 18:00:43 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-12-10/fesco.2014-12-10-18.00.log.html . Meeting summary --- * init process (thozza, 18:00:44) * init process (thozza, 18:01:17) * #1349 Fedora 22 scheduling strategy (and beyond) (thozza, 18:07:31) * AGREED: Postpone the ticket to next week's meeting since mattdm can't attend today's meeting (+6, 0, -0) (thozza, 18:12:07) * #1370 requesting exception for linking include-what-you-use with llvm-static (thozza, 18:12:18) * AGREED: close and ask them to talk to FPC? (+5, 0, -0) (thozza, 18:18:35) * #1371 Nonresponsive maintainer: clockfor (thozza, 18:18:43) * AGREED: Reassign python-pyudev to dshea (+5, 0, -0) (thozza, 18:20:51) * Next week's chair (thozza, 18:21:12) * nirik to chair next week's meeting (thozza, 18:23:04) * Open Floor (thozza, 18:23:14) * FESCo thanks everyone for great Fedora 21 release! (thozza, 18:24:08) Meeting ended at 18:26:43 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * thozza (40) * nirik (9) * zodbot (8) * mattdm (7) * kalev (7) * sgallagh (6) * t8m (5) * jwboyer (3) * dgilmore (1) * mmaslano (0) * mitr (0) * stickster (0) * jwb (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2014-12-10)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-12-10 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1349 Fedora 22 scheduling strategy (and beyond) .fesco 1349 https://fedorahosted.org/fesco/ticket/1349 = New business = #topic #1370 requesting exception for linking include-what-you-use with llvm-static .fesco 1370 https://fedorahosted.org/fesco/ticket/1370 #topic #1371 Nonresponsive maintainer: clockfor .fesco 1371 https://fedorahosted.org/fesco/ticket/1371 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On 11/21/2014 09:04 AM, P J P wrote: On Friday, 21 November 2014 1:24 PM, Florian Weimer wrote: On 11/21/2014 08:34 AM, Jan Kratochvil wrote: Almost all of my Fedora installations are test VMs where any security is irrelevant. Okay. But does enabling root login offer any significant benefit in that? IOW, if it's disabled by default, would it cause any significant inconvenience/troubles?? If not, it better be disabled by default. For example for me it would be some inconvenience. I also use a lot of Fedora VMs for testing and none of them has regular user, just root. However I can see the benefits of disabling root login by default. Especially from the security point of view. I think it would be a good move. Regards, Tomas I think it's a valid use case, but rather poorly supported at the moment. For example, there should be completely seemless SSH login from virt-manager for user-manageable virtual machines (both as root and the user). My point is that once we address this (most likely through some configuration generation during VM setup), we can also switch PermitRootLogin on. You mean off? Or that we disable it by default and enable it while setting up a new VM? --- Regards -Prasad http://feedmug.com -- 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: Summary/Minutes from today's FESCo Meeting (2014-11-19)
On 11/20/2014 08:05 AM, Till Maas wrote: On Wed, Nov 19, 2014 at 03:06:11PM -0500, Tomas Mraz wrote: * #1368 How to deal with F21 broken dependencies (t8m, 19:08:56) * AGREED: FESCo agrees to dropping the packages with broken dependencies listed in #1368 from both F21 and rawhide (+7, -0, 0:0) (t8m, 19:25:56) I retired the packages now. To make sure the final repo does not contain any packages with broken dependencies, the Freeze Exception process needs to be used to get packages from updates-testing that do not contain broken dependencies into the stable repo: https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process * AGREED: We will do the broken deps cleanup on Final Freeze from now on in the future Fedora releases (+8, -0, 0:0) (t8m, 19:30:41) * There will be warning sent to the affected maintainers at least 3 weeks in advance (t8m, 19:31:36) What happens with packages that get broken after the warning but before the Final Freeze? Regards Till Please someone correct me if I'm wrong, but all broken packages should be cleaned up after the Final Freeze. However we could send one more up-to-date reminder after the Freeze. Regards, Tomas -- 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: Idea: Ability to define dependencies between coprs (correctly)
On 10/02/2014 05:48 PM, Honza Horak wrote:
On 10/02/2014 05:18 PM, Pierre-Yves Chibon wrote:
On Thu, Oct 02, 2014 at 05:00:40PM +0200, Honza Horak wrote:
Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is
available for installing dependencies during building in copr. Using this
dependent repo link we are able to build packages in coprA with dependencies
in another coprB.
However, when enabling only coprA and installing some packages from this
copr, we can miss some packages from coprB, because those packages are not
available since coprB is not enabled.
Solution:
We should be able to define dependency between coprs correctly. When
creating coprA, we would add one or more depended coprs ('userB/coprB')
instead of repo link. Then all packages from these coprs would be available
during build, correct buildroots would be used (no need to specify variables
$releasever and in addition, we would be able to provide correct (all) RPMs
also when *installing* coprs.
There are basically two ways how to implement this on the users' side:
1) Simpler, preferred by Mirek, copr maintainer (CC'd):
'copr' plugin in dnf would include -r option, which would basically
installed all related coprs. That means when running `dnf copr enable -r
userA/coprA`, user would end with two coprs enabled: userA/coprA and
userB/coprB.
2) More complicated, preferred by me :) :
copr A repository from example above would not only include RPMs build as
part of this copr, but would include also packages from copr B. That means
that when running `dnf copr enable userA/coprA`, user would not need to
install userB/coprB repository and would have all packages available.
Both ways struggle with refreshing data:
* in 1) we might need to refresh coprs enabled (on the users' side)
* in 2) we would need to re-create repodata in depended coprA if coprB gets
changed (on the server's side).
What about putting the definition of the coprA on the coprB, ie at:
https://copr.fedoraproject.org/coprs/pingou/subsurface/repo/fedora-19/pingou-subsurface-fedora-19.repo
include the definition of the repo this copr depends on (ok bad example for
this
specific copr).
This way, it's rather clear to the user that the packages are coming from two
distinct copr, there no need to change dnf and we don't mix up in one repo
packages potentially built by different people.
That does imply that existing .repo file might have to be updated.
Yeah, I like that idea, that would remove some obstacles mentioned for
solution
1) above. I'm not sure though if the depended coprs can be called the same as
the original (we would have two similar repos enabled) or we would have to
call
them differently. Just quick test does not show any issues with more repos
with
the same name.
Honza
Different repos inside a single repo file will be still shown as different
repos when installing a packages from them. Therefore should not cause any
problems.
However in thins case it might be worth deciding if such .repo should be named
in a way to express it contains also a bundle of dependent repos.
Regards,
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
--
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: Idea: Ability to define dependencies between coprs (correctly)
On 10/03/2014 08:24 AM, Bohuslav Kabrda wrote:
- Original Message -
Hi all,
I have a proposal that would change how dependencies are defined in copr:
Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is
available for installing dependencies during building in copr. Using
this dependent repo link we are able to build packages in coprA with
dependencies in another coprB.
However, when enabling only coprA and installing some packages from this
copr, we can miss some packages from coprB, because those packages are
not available since coprB is not enabled.
Solution:
We should be able to define dependency between coprs correctly. When
creating coprA, we would add one or more depended coprs ('userB/coprB')
instead of repo link. Then all packages from these coprs would be
available during build, correct buildroots would be used (no need to
specify variables $releasever and in addition, we would be able to
provide correct (all) RPMs also when *installing* coprs.
There are basically two ways how to implement this on the users' side:
1) Simpler, preferred by Mirek, copr maintainer (CC'd):
'copr' plugin in dnf would include -r option, which would basically
installed all related coprs. That means when running `dnf copr enable -r
userA/coprA`, user would end with two coprs enabled: userA/coprA and
userB/coprB.
2) More complicated, preferred by me :) :
copr A repository from example above would not only include RPMs build
as part of this copr, but would include also packages from copr B. That
means that when running `dnf copr enable userA/coprA`, user would not
need to install userB/coprB repository and would have all packages
available.
3) (And I think that I've already heard this idea from someone) I think it'd
be better to:
- Put the copr repofiles into RPMs and put all these RPMs in a single repo.
- These repofile RPMs can depend on each other.
- dnf copr enable installs an RPM from this repo.
- When a dependency between repos change, repofile RPMs will be updated. When
user runs dnf update, he will get the new repofile RPM build, which will
have dependencies changed properly - so dnf will install these, too.
Both ways struggle with refreshing data:
* in 1) we might need to refresh coprs enabled (on the users' side)
* in 2) we would need to re-create repodata in depended coprA if coprB
I think that 3) is ok from this POV. The problem here can be, that in 3), dnf
would on update technically enable other copr repos without explicit user
approval. I'm not sure whether this is a problem or not, though.
Well, dnf/yum should show you what will be installed/enabled as dependencies,
so the user is kind of informed what extra repos will be installed and enabled.
gets changed (on the server's side).
Let's discuss this a bit, I'm eager to hear your opinions.
Cheers,
Honza
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
planned bind-pkcs11 changes in F20+
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all. I would like to inform everyone about changes I plan to do in Fedora 20+ due to Bug 1097752 (Support for native PKCS#11 interface - needed by FreeIPA). Currently there is a bind-pkcs11 package which includes couple of utilities needed for working with PKCS#11. - From the user feedback I got during the past year or so, utilities from PKCS#11 didn't work much. I backported the native PKCS#11 functionality from Bind 9.10 and plan to add/change the following sub-packages: bind-pkcs11 - will contain special version of named (named-pkcs11) which is compiled with the native PKCS#11 and doesn't use OpenSSL, for crypto, but some HSM. bind-pkcs11-libs - libdns and libisc compiled with native PKCS#11 functionality. These will be distributed as libdns-pkcs11 and libisc-pkcs11. bind-pkcs11-devel - development files for the native PKCS#11 versions of libisc and libdns. bind-pkcs11-utils - will provide utilities previously provided by the bind-pkcs11 package. The update path will be solved as described in Packaging guidelines. These utilities are compiled with native PKCS#11, too. If this changes could break someone's setup, please let me know so we can work on some solution. Otherwise I'll do the changes some day next week. Thank you. Regards, - -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUJBjZAAoJEMWIetUdnzwti44H/11yHgr1tpvPOYuyqrnP3+wl UV5yiB5f8ygZdal9IclU7b9F/MrsB/lpsXVmyHHB3tPEF2ed9yTMyhNM3MrAV/pe Fu8VygUqkiL3ZC1R5jVL/qLK590RO374oLD7UTaHfC1zfu1MnVf3G+2NwtSlXUP1 SAHTU5jCgBf3/9sqykPjuxZ4nwiImpAziMaMrzDzqTVGHmwgO7+W02HVo0wAD9dl VJbdOL+HXIKQFIHyLDLJq+Zfn+qR06vG2L+aIPkAjkIsOM2ied9TtIuT+NQZQEs0 k0ccAL59Nr1aUtBDaNVWhf+AZ6cZBcWvKxYqooiRh2BaWs4JbWrm81PnIa/a4PU= =2KjZ -END PGP SIGNATURE- -- 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: planned bind-pkcs11 changes in F20+
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/25/2014 05:18 PM, Paul Wouters wrote: On Thu, 25 Sep 2014, Tomas Hozza wrote: I would like to inform everyone about changes I plan to do in Fedora 20+ due to Bug 1097752 (Support for native PKCS#11 interface - needed by FreeIPA). Currently there is a bind-pkcs11 package which includes couple of utilities needed for working with PKCS#11. - From the user feedback I got during the past year or so, utilities from PKCS#11 didn't work much. I backported the native PKCS#11 functionality from Bind 9.10 and plan to add/change the following sub-packages: Sounds good to me. The only people this would affect are those running bind with an hsm, and we'd hope they would be on rhel/centos to begin with. But even if this moves gradually into there, it looks good. Good to hear that. I think Fedora is a great place for people wanting to try it out. I don't expect someone to run it in production enterprise environment on Fedora. I was hoping bind 9.10+ would be able to do runtime pkcs#11 hsm stuff :/ without the need for hacking and recompiling. Yeah, I was hoping for the same thing. Unfortunately it is not possible even with BIND 9.10 (which will be in F22). Upstream is opened to patches, but don't have time and interest to do it themselves. - From my point of view the ideal situation would be if BIND could fall back to using OpenSSL if there is no HSM configured (or working). Well, I might look into it in the future, but it is a low priority item for me, too. Unfortunately this adds yet another compiled version of named (there is already named-sdb). However the positive thing is that this way it will not change anything for current named users. Thanks for your opinion. Regards, - -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUJDRtAAoJEMWIetUdnzwtU/YIAMwMqdz7p2SUVvDXl46TfAb8 W+kyKxdyYLCyM5Am85bEN70FkLiMMaP1Y1VsGh3IpQr/j67/mX39iZSp8qyMsig0 Z0ooCV1TyupqnYzBzQoHjJE7zMHz/50MNhEkrrBHwel1iXa0As6H2Wiexn/enqQe CkzMnR9fvVNs2kY/htx40MSqSXELegQk0W90XhrvXG7QUx4kcraPAAhJwRjkNezp rrad1Xb19WUDkv2/990bppnkja6lN1I9efKyLDO7jIQ5JVYc4pNK4C6769uP95RO K1WaIEh089XwmVa0JkdiGNRQTId1OtqsSNiKIodsMoBYeoukl85cMi3ldYYoYqk= =N1i5 -END PGP SIGNATURE- -- 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: F22 Self Contained Change: BIND version 9.10
On 09/16/2014 01:34 PM, Jaroslav Reznik wrote: = Proposed Self Contained Change: BIND version 9.10 = https://fedoraproject.org/wiki/Changes/BIND_9.10 Change owner(s): Tomas Hozza tho...@redhat.com BIND (Berkeley Internet Name Domain) version 9.10 is the latest stable major update of the widely used DNS server. Besides new features, some settings defaults have changed since the previous major version (9.9). == Detailed Description == FULL BIND 9.10 RELEASE NOTES [1] === New features === * New zone file format, map, stores zone data in a format that can be mapped directly into memory, allowing significantly faster zone loading. * New tool delv (domain entity lookup and validation) with dig-like semantics for looking up DNS data and performing internal DNSSEC validation has been added. * New prefetch option improving the recursive resolver performance has been added. * Improved EDNS processing allowing better resolver performance. * Substantial improvements have been made in response-policy zone (RPZ) performance. * ACLs can now be specified based on geographic location using the MaxMind GeoIP databases. * The statistics channel can now provide data in JSON format as well as XML. * The new in-view zone option allows zone data to be shared between views, so that multiple views can serve the same zones authoritatively without storing multiple copies in memory. * Native PKCS#11 API has been added. This allows BIND 9 cryptography functions to use the PKCS#11 API natively, so that BIND can drive a cryptographic hardware service module (HSM) directly instead of using a modified OpenSSL as an intermediary (Native PKCS#11 is known to work with the Thales nShield HSM and with SoftHSM version 2 from the Open DNSSEC project.). * New tool named-rrchecker can be used to check the syntax of individual resource records, and optionally to convert them to the format used for unknown record types. * New tool dnssec-importkey allows offline DNSSEC keys (i.e., keys whose private data is not stored on the system on which named is running) to be published or deleted on schedule using automatic DNSKEY management. * Network interfaces are re-scanned automatically whenever they change. Use automatic-interface-scan no; to disable this feature. ** Added rndc scan to trigger an interface scan manually. * New max-zone-ttl option enforces maximum TTLs for zones. If loading a zone containing a higher TTL, the load fails. DDNS updates with higher TTLs are accepted but the TTL is truncated. * Multiple DLZ databases can now be configured, and are searched in order to find one that can answer an incoming query. * named-checkzone and named-compilezone can now read journal files. === Feature changes === * The version 3 XML schema for the statistics channel, including new statistics and a flattened XML tree for faster parsing, is no longer optional. The version 2 XML schema is now deprecated. * named now listens on IPv6 as well as IPv4 interfaces by default. * The internal and export versions of the BIND libraries (libisc, libdns, etc) have been unified so that external library clients can use the same libraries as BIND itself. * The default setting for the -U option (setting the number of UDP listeners per interface) has been adjusted to improve performance. * Adaptive mutex locks are now used on systems which support them. * rndc flushtree now flushes matching records from the address database and bad cache as well as the DNS cache. (Previously only the DNS cache was flushed.) * The isc_bitstring API is no longer used and has been removed from the libisc library. * The timestamps included in RRSIG records can now be read as integers indicating the number of seconds since the UNIX epoch, in addition to being read as formatted dates in MMDDHHMMSS format. == Scope == * Proposal owners: Rebase the package to the latest 9.10 minor version and resolve possible packaging issues. (Also rebuild all currently existing dependent packages listed below) * Other developers: Rebuild dependent packages (dhcp, dnsperf, bind-dyndb- ldap) ** Owner of this feature is co-maintainer of all dependent packages. He will do the necessary rebuilds himself in cooperation with dependent packages owners. * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) [1] http://ftp.isc.org/isc/bind9/9.10.0-P2/RELEASE-NOTES-BIND-9.10.0-P2.txt ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce You can try BIND 9.10.1b2 using COPR repo: http://copr-fe.cloud.fedoraproject.org/coprs/thozza/bind-9.10.1b2/ I'll update the COPR in the mean time since there is already a RC1. Dependent packages can be found here: http://copr-fe.cloud.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2014-08-20)
=== #fedora-meeting: FESCO (2014-08-20) === Meeting started by thozza at 17:04:28 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-08-20/fesco.2014-08-20-17.04.log.html . Meeting summary --- * init process (thozza, 17:04:48) * #1178 Fedora 21 scheduling strategy (thozza, 17:08:36) * AGREED: Go into freeze the day after we have a usable TC. revisit schedule next meeting to see if we need to adjust/delay/change anything. (+6) (thozza, 17:24:56) * ACTION: dgilmore will send the heads-up on devel list once we have TC (day before freeze) (thozza, 17:25:24) * #1322 F21 Changes - Progress on Changes Freeze (thozza, 17:25:43) * ACTION: thozza will update the ticket asking for update on Changes progress (thozza, 17:28:58) * #1330 F22 System Wide Change: Perl 5.20 - https://fedoraproject.org/wiki/Changes/perl5.20 (thozza, 17:29:12) * AGREED: F22 System Wide Change: Perl 5.20 has been approved (+6) (thozza, 17:34:42) * #1331 The package pipelight violates Fedora guidelines regarding (thozza, 17:34:56) * ACTION: sgallagh to discuss proper review policy with the approver. (sgallagh, 17:38:46) * #1332 F22 retire orphan packags after 4 weeks instead of once per release (thozza, 17:53:22) * ACTION: sgallagh to talk to maintainer as well (previous topic) (sgallagh, 17:53:45) * ACTION: thozza ask reporter to move the discussion to the devel list (thozza, 18:04:37) * #1333 OpenJDK maintainer refuses to address F20-F21 upgrade bug once per release (thozza, 18:04:48) * LINK: https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#To_Fedora_21_pre-release should work (kalev, 18:14:57) * AGREED: Ask jvanek to make f20-f21 upgrades result in a working system, reasonably similar to a clean f21 install. FESCo declares BZ 1130247 to be a blocker for F21 Beta. (+6) (thozza, 18:19:57) * Next week's chair (thozza, 18:20:34) * nirik to chair next week’s meeting (thozza, 18:23:56) * Open Floor (thozza, 18:24:11) Meeting ended at 18:32:41 UTC. Action Items * dgilmore will send the heads-up on devel list once we have TC (day before freeze) * thozza will update the ticket asking for update on Changes progress * sgallagh to discuss proper review policy with the approver. * sgallagh to talk to maintainer as well (previous topic) * thozza ask reporter to move the discussion to the devel list Action Items, by person --- * dgilmore * dgilmore will send the heads-up on devel list once we have TC (day before freeze) * sgallagh * sgallagh to discuss proper review policy with the approver. * sgallagh to talk to maintainer as well (previous topic) * thozza * thozza will update the ticket asking for update on Changes progress * thozza ask reporter to move the discussion to the devel list * **UNASSIGNED** * (none) People Present (lines said) --- * thozza (59) * nirik (47) * sgallagh (45) * jvanek (32) * mitr (28) * kalev (27) * jwb (10) * dgilmore (7) * zodbot (5) * mmaslano (0) * mattdm (0) * t8m (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2014-08-20)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '-MM-DD 17:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1178 Fedora 21 scheduling strategy .fesco 1178 https://fedorahosted.org/fesco/ticket/1178 #topic #1322 F21 Changes - Progress on Changes Freeze .fesco 1322 https://fedorahosted.org/fesco/ticket/1322 = New business = #topic #1330 F22 System Wide Change: Perl 5.20 - https://fedoraproject.org/wiki/Changes/perl5.20 .fesco 1330 https://fedorahosted.org/fesco/ticket/1330 #topic #1331 The package pipelight violates Fedora guidelines regarding downloading of 3rd party software .fesco 1331 https://fedorahosted.org/fesco/ticket/1331 #topic #1332 F22 retire orphan packags after 4 weeks instead of once per release .fesco 1332 https://fedorahosted.org/fesco/ticket/1332 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- 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: Schedule for Wednesday's FESCo Meeting (2014-08-20)
On Tue 19 Aug 2014 01:40:55 PM CEST, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/19/2014 04:14 AM, Tomas Hozza wrote: Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '-MM-DD 17:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1178 Fedora 21 scheduling strategy .fesco 1178 https://fedorahosted.org/fesco/ticket/1178 #topic #1322 F21 Changes - Progress on Changes Freeze .fesco 1322 https://fedorahosted.org/fesco/ticket/1322 = New business = #topic #1330 F22 System Wide Change: Perl 5.20 - https://fedoraproject.org/wiki/Changes/perl5.20 .fesco 1330 https://fedorahosted.org/fesco/ticket/1330 #topic #1331 The package pipelight violates Fedora guidelines regarding downloading of 3rd party software .fesco 1331 https://fedorahosted.org/fesco/ticket/1331 #topic #1332 F22 retire orphan packags after 4 weeks instead of once per release .fesco 1332 https://fedorahosted.org/fesco/ticket/1332 #topic #1333 OpenJDK maintainer refuses to address F20-F21 upgrade bug once per release .fesco 1333 https://fedorahosted.org/fesco/ticket/1333 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. I opened https://fedorahosted.org/fesco/ticket/1333 this morning; can we get that onto the agenda for tomorrow as well, please? Sure, I added the ticket to the New Business section. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlPzN8cACgkQeiVVYja6o6O8mQCfZBFfxus/PDueLVLi3jXZ668+ xmEAn0f1SGeKarhEsBswcGixV6c8G9ow =qoqR -END PGP SIGNATURE- Regards, Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
BIND 9.10.1 beta with seccomp functionality
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. ISC is working on new BIND 9.10 release which includes the seccomp functionality. It can be turned on by configuring BIND before build with --enable-seccomp. ISC asked me to kindly ask Fedora community if they would be willing to test it. Currently I'm working on rebasing BIND to 9.10 in rawhide. However it is still not finished. Since DHCP (including dhclient) depends on BIND libraries I'm not able to easily provide a testing RPMs that would be installable. In the future I would like to turn the feature on by default. So if you are willing to test the feature, you can download latest BIND 9.10.1b2 on http://www.isc.org/downloads/ Configure it with --enable-seccomp and you're good to go. You can send your feedback to bind-beta-respo...@lists.isc.org, bind-us...@lists.isc.org or bind-b...@isc.org Some words about the feature from the contributor: It goes further than a chroot. chroot limits an attacker to a filesystem. it doesn't prevent the attacker from running his exploit aka nefarious code and making socket connections over the internet that would give him some kind of backdoor access where he can remotely execute his code. That's where seccomp kicks in, it acts as a 2nd wall of defence. In case of a security hole being present in the server process, it goes further than a chroot, it prevents the attacker from making socket connections orexecuting his code, as his playing field is significantly reduced. There's very little he can do.” Thank you. Regards, - -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJT82i/AAoJEMWIetUdnzwtooYH/1hffLhpDtY1zTPNVtSlFLUx 236mJQGZMS5jsHAKPtd354qLCSMSIBTEeeGPCUkV9YC3ZtrF+wT6FCN1XFgDylpr 7S2toCAVOpjbPIUIOJZ8HvRZENb//KGxUHg8GrlIfHZMeXB9EXhvaTcxLC1QTX04 JSZyQKXIaDWurTGM/AQESAwHkIWK1vaubmrI2dt8L0mp9e5RWc3N/sb5XAup0jfa zfkP/oPsmeS6mZvKdoc/BiwDDj8bLm8NBLHFO++tES0e43HnWAo9+H4HqSNuX5JQ 0q4a11zy55VtL8G99kzGN64gdvtXbiNDVuxulecWxxK9BUncHv3aXu5t4ggO0yg= =MtKc -END PGP SIGNATURE- -- 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: BIND 9.10.1 beta with seccomp functionality
On Tue 19 Aug 2014 05:12:31 PM CEST, Chris Adams wrote: Once upon a time, Tomas Hozza tho...@redhat.com said: That's where seccomp kicks in, it acts as a 2nd wall of defence. In case of a security hole being present in the server process, it goes further than a chroot, it prevents the attacker from making socket connections orexecuting his code, as his playing field is significantly reduced. There's very little he can do.” How is that different from an SELinux policy? How is the additional resitrction handled (if it isn't SELinux, what mechanism is used to do the restriction)? I'm not such expert in this field to answer your question. However by googling you can find some information about seccomp: https://wiki.mozilla.org/Security/Sandbox/Seccomp http://outflux.net/teach-seccomp/ However I would love to see some opinion and response from someone working on SELinux and security. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Retiring bind10 in F21+
Hi. BIND10 project developed by ISC ended earlier this year [1]. Therefore as of today I'm retiring the bind10 package from Fedora 21+. The DHCP servers part is already submitted for package review in Fedora [2]. [1] http://www.isc.org/blogs/isc-concludes-bind-10-development-with-release-1-2-project-renamed-bundy/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1130617 Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: Non-responsive maintainer: Deji Akingunola (fas: deji)
- Original Message - From: Kevin Fenzi ke...@scrye.com To: devel@lists.fedoraproject.org Sent: Saturday, July 26, 2014 7:17:24 PM Subject: Re: Non-responsive maintainer: Deji Akingunola (fas: deji) On Fri, 27 Jun 2014 09:01:33 -0600 Kevin Fenzi ke...@scrye.com wrote: On Fri, 27 Jun 2014 22:03:30 +0800 Christopher Meng cicku...@gmail.com wrote: My opinion is, you should only comaintain what you want, not take over other's packages. If FESCo member could give consent of adding someone as an admin(not the point of the contact) of a package instead of orphaning lots of packages, that will be helpful. The plan is to orphan the packages, but leave the old point of contact with acls. That way someone active can take over the package, but if the old point of contact comes back they can just join right back in. This way the package gets active folks caring for it and the former point of contact can come back anytime. Sorry for the long delay here. ;( There was a issue with the pkgdb2 api to do this, then I was traveling, etc. It's now been done. The following packages are looking for a new point of contact on at least one branch: (Note that many of them have co-maintainers, so do check with them to see if any of them would like to become the new point of contact): atlas Taken by fkluknav Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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: Attempting to contact unresponsive maintainer - jkoncick
- Original Message - Greetings, we've been told that the email addresses for this package maintainer is no longer valid. I'm starting the unresponsive maintainer policy to find out if they are still interested in maintaining their packages (and if so, have them update their email addresses in FAS). If they're not interested in maintaining or we can't locate them I'll have FESCo orphan the packages so that others can take them over. If you have a way to contact this maintainer, please let them know that we'd appreciate knowing what to do with their packages. Thanks! * jkoncick - former email address: jkonc...@redhat.com https://admin.fedoraproject.org/pkgdb/packager/jkoncick If we don't hear anything in a week, we will be removing their acls and will need to find new point of contacts, etc. Thanks, kevin Hi Jaromir was an intern at Red Hat and finished today. I think it is OK if you remove his acls right away. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
FESCo candidature announcement
Hi all. I would like to announce my candidature for FESCo member. Besides goals I'm interested [1] in I would like to stress, that I'm prepared to fight for changes, that would be beneficial for Fedora users and developers. I don't want to make decisions on any topic without prior research and proper understanding. I think all important changes should be thoroughly discussed and not made silently. Have you any questions, feel free to ping me on IRC (#fedora-devel) or drop an email. Tomas [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations#Candidates -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Split of bind-chroot package in Fedora rawhide branch
Hi. I would like to prevent unpleasant surprises and announce, that bind-chroot sub-package of bind has been split into two sub-packages in the Fedora rawhide branch. Previously the bind-chroot sub-package contained named-chroot.service enabling users to run named in a chroot environment and also named-sdb-chroot.service enabling users to run named-sdb in a chroot environment. From now on, there are two subpackages: - 'bind-chroot' - for running named in a chroot (nothing changes) - 'bind-sdb-chroot' - for running named-sdb in a chroot User that want to run named-sdb in a chroot must install the 'bind-sdb-chroot' package explicitly. This change is a part of fixing Bug #997030. The package will be also NOT installed if updating to Fedora rawhide, because it cannot be currently done (AFAIK) without creating unwanted dependencies. As an addition named-sdb now uses its own chroot path '/var/named/chroot_sdb'. Regards, Tomas Hozza ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: PSA: If you are C/C++ developer, use cppcheck
- Original Message - Hi On Tue, Dec 17, 2013 at 12:47 PM, Daniel P. Berrange wrote: The issues reported against libvirt all appear to be false positives. Not entirely surprising since we already have coverity run against libvirt code nightly. Thanks for the quick response. Does Red Hat run it only for packages in RHEL or it is run against all Fedora packages? If not, would it be possible for Red Hat to do so and publish the results on a regular basis? That might be a useful service. We run the scans also on Fedora packages regularly. However I'm not sure if also for fedora packages that doesn't have Red Hat maintainers. Any Red Hat Engineer has the Coverity tool available to use and can scan any open-source project with it. I personally scanned some network daemons like BIND, ISC DHCP, dnsmasq, unbound, Squid, and also couple of other projects and sent a ton of patches to upstream projects. Now I'm doing only scans for possible added issues, when there is a new version. Publishing scan results for all Fedora packages might not be very good idea, since the static analysis can find issues with possible security impact. Also Coverity offers their tool to open-source projects for free [1]. I think some projects are already using it (at least Squid). So if upstream projects are interested, they can sign up for free. [1] https://scan.coverity.com/ Regards, Tomas Hozza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unresponsive maintainers of dependent packages
Hi. Before my question, little bit of introduction: --- I'm the maintainer of 'openobex' package (library) which was rebased to the latest version in rawhide on the end of September this year. The rebase was announced 2 weeks in advance on fedora-devel and I also CC-ed all maintainers of dependent packages about the change. There was an API change, so more work than just rebuilding dependent packages is needed. I emailed maintainers of dependent packages and also created Bug [1] for each component, to track those rebuilds. So far some dependent packages has been deprecated, but there are still three that have broken dependencies and their maintainers seem to not care. Question: - The main problem for me is that the buildsystem (koji) emails me every day and for every dependent package that their dependencies are broken. Can I ask these packages to be deprecated in rawhide, or what can I do with them? I don't want to take maintenance of those packages. Dependent packages I have problem with are: - obexfs - obexftp - libopensync-plugin-irmc Thanks in advance for any help/opinion. Regards, Tomas Hozza [1] https://bugzilla.redhat.com/show_bug.cgi?id=1014160 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Heads up - updating openobex in rawhide to 1.7.1 - API change
Hi. I'm going to update the openobex package in rawhide to the latest version (1.7.1) in about two weeks. Unfortunately this version breaks the API, so dependent packages need to be patched in order to be build. Needed changes should be small. Since the rebase is from version 1.5 - 1.7.1 following changes are relevant: Upgrade guide from previous version of openobex === Upgrading to version 1.7 When using an event loop that triggers on incoming data, you must call OBEX_HandleInput() after each call to OBEX_Request() to actually send the request. Upgrading to version 1.6 The function OBEX_UnicodeToAscii() and its counterpart OBEX_AsciiToUnicode() are gone. Please use the more complete functionality from your toolkit. (For example libunistring - http://www.gnu.org/software/libunistring/manual/libunistring.html#uniconv_002eh) If you use one of the functions InOBEX_ServerRegister() and InOBEX_TransportConnect(), please change to TcpOBEX_ServerRegister() and TcpOBEX_TransportConnect(). The functions OBEX_GetCustomData() and OBEX_SetCustomData() will really only work with OBEX_TRANS_CUSTOM. Also, obex_t and obex_object_t changed the declared type. If you pass it around, make sure to use them as pointer. To use the bluetooth function, include the bluetooth headers of your system before including openobex/obex.h or define bt_addr_t to the proper type. The function OBEX_FindInterfaces is replaced by the functions OBEX_EnumerateInterfaces() and OBEX_GetInterfaceByIndex(). The new version of openobex package can be found here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5918748 or http://thozza.fedorapeople.org/openobex-1.7.1-repo/ Dependent packages are: ircp-tray-0:0.7.6-3.fc20 - http://thozza.fedorapeople.org/openobex-1.7.1-rebuilds_results/results_ircp-tray/ libbtctl-0:0.11.1-14.fc20 - http://thozza.fedorapeople.org/openobex-1.7.1-rebuilds_results/results_libbtctl/ libopensync-plugin-irmc-1:0.22-7.fc20 - http://thozza.fedorapeople.org/openobex-1.7.1-rebuilds_results/results_libopensync-plugin-irmc/ obex-data-server-1:0.4.6-6.fc20 - http://thozza.fedorapeople.org/openobex-1.7.1-rebuilds_results/results_obex-data-server/ obexfs-0:0.12-7.fc20 - http://thozza.fedorapeople.org/openobex-1.7.1-rebuilds_results/results_obexfs/ obexftp-0:0.23-15.fc20.x86_64 - http://thozza.fedorapeople.org/openobex-1.7.1-rebuilds_results/results_obexftp/ syncevolution-1:1.3.99.3-6.fc20.x86_64 - http://thozza.fedorapeople.org/openobex-1.7.1-rebuilds_results/results_syncevolution/ If someone thinks we should not rebase openobex to the latest version and has a good reason for it, feel free to replay to this email. Thanks! Regards, Tomas Hozza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
