Re: updates-testing: multilib broken for days now
> On 09/07/15 12:39, Miloslav Trmač wrote: > >>> Protected multilib versions: polkit-0.113-1.fc21.x86_64 != > >>> polkit-0.112-7.fc21.1.i686 > >> > >> This is due to polkit splitting out a polkit-libs package between those > >> two versions. This makes it only include the polkit-libs package > >> instead of a polkit.i686. > >> > >> You should be able to just remove the old polkit.i686, but I agree it > >> needs to be handed by the package cleanly for upgrades. > > > > Oops. Is there a way to handle this cleanly at all? I can’t just do > > polkit-libs.i686 Obsoletes: polkit.i686, that would break 32-bit-only > > systems. > > How about: > > Obsoletes: polkit < 0.112-7 > (assuming this is the EVR at which the split was introduced) > > https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#Splitting_libraries_into_separate_packages > > On a 32-bit system, both polkit and polkit-libs should be updated to > polkit-0.112-7, whilst on x86_64, polkit-libs-0.112-7.i386 will obsolete > polkit-0.112-1.i386 and the x86_64 versions will upgrade to 0.112-7 as > expected. That doesn’t quite work; yum sees this Obsoletes: and decides to replace polkit with polkit-libs, and then there is no polkit expected to be installed, so the upgraded one will not be installed either. In most systems this happens to work OK because the polkit package is dragged back in through one of several explicit dependencies on polkit, but a truly minimal install will end up losing the daemon. I will just revert the split on F21. (Though the same problem should be happening on F21→F22 upgrades because polkit has been split on F22 from the start. There were no reports of this problem so far.) Mirek -- 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: updates-testing: multilib broken for days now
> On Wed, 8 Jul 2015 21:30:40 +0200 > Reindl Harald wrote: > > ...snip... > > > Protected multilib versions: polkit-0.113-1.fc21.x86_64 != > > polkit-0.112-7.fc21.1.i686 > > This is due to polkit splitting out a polkit-libs package between those > two versions. This makes it only include the polkit-libs package > instead of a polkit.i686. > > You should be able to just remove the old polkit.i686, but I agree it > needs to be handed by the package cleanly for upgrades. Oops. Is there a way to handle this cleanly at all? I can’t just do polkit-libs.i686 Obsoletes: polkit.i686, that would break 32-bit-only systems. Mirek -- 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 Self Contained Change: Astronomy Spin
> On Fri, Jun 26, 2015 at 2:36 PM, Christian Dersch > wrote: > > Additional info: Of course an "Astronomy Tools" group is a nice idea too! > > But it doesn't replace the Spin as the "download, boot and try it" idea > > doesn't work without a spin. > > A possible work around: > It's possible to install the group with live media without installing > it. That may not work too well when you are far away from the cities to avoid light pollution; also, the read-write overlay on live media has a not-that-large maximum size (500 MB)? For off-line use, a ready-to-go USB stick could be quite useful. Mirek -- 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
> > 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 don't want, in the Network panel, to be talking to 2 pieces of software that > I'll need to aggregate myself to get a complete picture. That’s kind of surprising; users should see a view that makes sense to them, not a reflection of the underlying implementation stack. Isn’t it anyway a pretty common situation to talk to two or more services in one dialog? E.g. the sharing panel definitely talks to several services. I agree that you don’t want to talk to two pieces of software which tell you different answers to the same question—but AFAICS that should be an argument in favor of integrating with dnssec-trigger directly instead of having NetworkManager proxy (and possibly modify) everything. (Well, assuming dnssec-trigger and NM talk to each other enough to keep in sync, but the dnssec-trigger<->NM interface does not need to be the same as GUI<->NM nor GUI<->dnssec-trigger one.) Mirek -- 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: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
> On 16.06.2015 00:30, Susi Lehtola wrote:
> > On 06/14/2015 03:02 PM, Sandro Mani wrote:
> >> On 14.06.2015 16:28, Sandro Mani wrote:
> >>> Rules to generate such requires/provides:
> >>> * Provides: if the path of the library starts with $MPI_LIB, append
> >>> the (openmpi) resp (mpich) to the provides string
> >>> * Requires: if the path of the scanned object starts with $MPI_LIB and
> >>> the required library exists in $MPI_LIB, add (openmpi) resp (mpich) to
> >>> the requires string
> >>>
> >>> Overriding the find-requires.sh could be done with a
> >>> %{?openmpi_package_header}.
> >> Concrete examples:
> >>
> >> https://smani.fedorapeople.org/mpi-find-provides
> >> https://smani.fedorapeople.org/mpi-find-requires
> >>
> >> Konsole output
> >> $ echo -e
> >> "/usr/lib64/openmpi/lib/libnglib-5.3.1.so\n/usr/lib64/libnglib-5.3.1.so"
> >> | ./mpi-find-provides
> >> libnglib-5.3.1.so()(64bit)(openmpi-x86_64)
> >> libnglib-5.3.1.so()(64bit)
> >
> > Sounds even better... although your links give HTTP 403.
> Thanks for the feedback. Permissions fixed, sorry about that.
>
> To discuss this further, should it be drafted as a Change and go to
> FESCO, or rather filed as an FPC ticket?
The find-* scripts should probably be a bug filed against RPM.
If written packaging guidelines are needed in addition to just adding the
scripts, that would be a FPC ticket.
A Change is necessary neither for new features in RPM (though you can write one
if you want users of F23 to know about it) nor for packaging guidelines
additions to be applied in future packages. A Change would be desirable if the
packaging guidelines change involved a coordinated mass change, i.e. “everyone
else please update your packages to help make this happen”.
Mirek
--
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: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
> On Mon, Jun 15, 2015 at 3:02 PM, Miloslav Trmač wrote: > > What would dnssec-trigger do if an attacker^Wlegitimate hotspot provider > > deliberately let the hotspot probe lookup and connection through, but kept > > redirecting everything else? > > Detect it and show the sandboxed browser. If that means that the user > has to type their Facebook password again, then the user is welcome to > do that. I don't see why we should make it easier to track users, > though. That’s what dnssec-trigger ideally _should_ do. What would it _actually_ do, e.g. with the current code? > Or we could proxy all traffic through the giant hole they'll create in > order to avoid being detected as a captive portal. /me ducks Nice ☺ More realistically, we could proxy the DNS fallback through there. > We could at least make these shenanigans harder by sending a > legitimate-looking UA header Yes > and hitting a non-static page that > answers some challenge rather than just saying "200 OK". I don’t think that would help; the hotspots tend to use a whitelist of “don’t intercept” addresses (which is after all easier than completely faking even a static reply), so seeing an unmodified hotspot detection page does not say anything about other pages being modified. Mirek -- 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: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
> Apple (foolishly) used to use something like http://apple.com/hotspot > on their main site itself, which meant that using a VPN on demand could > never protect apple.com because the iphone had to leave that domain out > of the vpn trigger list or else all hotspot detection would be broken. It > seems they have switched to captive.apple.com with returns "Success". Nowadays they randomly? choose from several different domains. See e.g. http://help.tanaza.com/customer/portal/articles/1317023-captive-portal-automatic-detection-avoid-login-popups . Mirek -- 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: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
Hello, > On Jun 13, 2015 4:28 AM, "Michael Catanzaro" < mcatanz...@gnome.org > wrote: > > On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote: > > > > > > > But that's not even right. Suppose you have a captive portal that > > > wants you to log in via your Google account. It can send you do > > > https://accounts.google.com , and your browser can verify the > > > certificate and show you an indication that the connection is secure. > > > Then you really can safely enter your password. > > > > Hmmm, I didn't realize legitimate portals might take you to the public > > Internet. > I think I've seen this in airports and in some hotel chains. Yes; sadly, many “legitimate portals” (easily 50% of the airport hotspots I have encoutered in Europe) are pretty much attackers. In particular, many of them want to bypass hotspot detection so that the log in screen does not appear in the sandboxed hotspot sign-on browser; by now it is a pretty standard feature of business access points to have a “bypass hotspot detection” checkbox. (For iOS, this has reportedly been done by recognizing an unique User-Agent used for the hotspot check; not sure about Android.)¹ They want to use the regular, unsandboxed, browser so that * password autofill works * credit card number autofill works * your Facebook login state is available to that you can easily “like” the hotspot provider (I’m not entirely sure but I think I did already see “like our page for 15 minutes of free internet” in a public hotspot) * your advertising tracking cookies transfer (for better targeting of ads on the hotspot login page, or so that you can be marked “visited airport $ABC” and related ads can be targeted at you in the future) What would dnssec-trigger do if an attacker^Wlegitimate hotspot provider deliberately let the hotspot probe lookup and connection through, but kept redirecting everything else? Mirek ¹ You can guess what this does to any applications which use unauthenticated HTTP to download data in the background: all that data suddenly becomes the hotspot login page and the application may not realize there is anything suspect about it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
> Generally the problem is that resolv.conf is quite limited and cannot express > lot of things, like trust levels and per-domain forwarding (using different > servers for queries related to different domains). > > One possibility how to solve this is to port applications to use different > library/API for name resolution but we have learn that this is not feasible > (recall the "everything to NSS" effort). The NSS consolidation lessons don’t quite apply because the essential requirement of that was “everything will use a single implementation” which is not actually a requirement in this case: it is only “everything will talk to the correct same resolver and will have the same assumptions about it being trusted for DNSSEC validation”. So one option you haven’t mentioned is: Keep all the current resolver libraries and their APIs, but modify their implementations to take their configuration from a different source; and have the local unbound, if any, use /etc/resolf.conf (along with other configuration sources?). If possible, this would be very nice in that it would allow us to keep /etc/resolv.conf as the _administrator_-targeted configuration file where the external/forwarding DNS resolvers are configured, while keeping the _internal implementation_-focused state (availability and address of the trusted local resolver, an implementation detail of DNSSEC rather than an administrator-visible configuration item) invisible/less visible to administrators, and in fact not even a part of API of any of the resolver libraries, and it would minimize users’ disruption. As it is now, we will end up with this weird “configuration” file in /etc which looks like just any other configuration file except this one is both _not_ user modifiable _and_ cannot be just removed. From the various small code snippets in this thread and elsewhere it seems that doing this would probably not be possible because the knowledge that “/etc/resolv.conf is where I read which resolver to send packets to” has leaked from the libraries to the applications, so merely patching resolvers would be insufficient. (And, honestly, ABIs should be code interfaces and not file formats, so I will not mourn for editable /etc/resolv.conf too much…) But, well, just in case it were actually possible… Mirek -- 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: DKMS is not installing the right kernel-devel package
> On Fri, Jun 12, 2015 at 7:24 AM, Neal Gompa wrote: > > What about some kind of virtual provides defined in repos/rpm/somewhere that > > would automatically grab the kernel-devel package associated with the exact > > kernel that is running at the time yum/dnf is installing a program that > > depends on it? That would allow for things like DKMS to function properly, > > since they'll have what they need to build kernel modules. Going forward, > > kernel upgrades will also drag in the appropriate kernel-devel packages to > > match, keeping things sane. > > That would help DKMS at the cost of breaking rpmfusion, koji, or any > other scenario where you want to build a kernel module for a kernel > that isn't running. The kernel-devel package is meant to be flexible > enough so that you can install it without having anything close to the > same kernel version actually running. I don’t think this would break the model: there would be no changes to packaging kernel-devel, you would still be able to install kernel-devel-$whateverversion, but a magic (dnf install ^kernel-devel-current) or “Requires: ^kernel-devel-current” would refer to a specific one. > It's worth pointing out that the Fedora DKMS package could implement > the logic you suggest in DKMS itself. Then it would either fail if > the relevant kernel-devel isn't installed (or kernel-PAE-devel, etc). > However, that still doesn't really make it an automated working > solution and still requires manual intervention to actually get it > installed. It is actually already fairly easy to usefully (but not reliably) automate this, copying an ugly hack from Chrome packaging, something like > %post dkms > the_details=… > echo 'dnf install kernel-devel-$the_details' | at now+1minute > As I said, there are no great solutions here. Yeah, the above is another example of that ☺ Mirek -- 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
Hello, > = Proposed System Wide Change: Default Local DNS Resolver = > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver > > 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. We’ve had earlier conversations about whether the resolver being used (local, remote, container host) is trusted to perform DNSSEC validation. How is this resolved? The Change page AFAICS doesn’t say. Do you e.g. plan to have a configuration file which tells libc/and other applications dealing with resolv.conf directly to know whether the resolver can be trusted for DNSSEC? Or is perhaps the design that any resolver in /etc/resolv.conf is always trusted for DNSSEC, and sysadmins need to ensure that this is true if they use a remote one? Mirek -- 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 Self Contained Change: Netizen Spin
> And generally I agree with the concern raised on the spins list > (https://lists.fedoraproject.org/pipermail/spins/2015-May/004222.html and > following) that the spin description can, at least by a quick read without > reading the actual kickstart, likely to be misunderstood to deliver more > than it actually does. For example, just including a tor package by no means > guarantees privacy (e.g. it does nothing about all the ways Fedora leaks > information about being Fedora). So, to be explicit: The spin description, and spin contents, need to be put in line, so that users installing the spin will get what they will expect to get by reading the description; either by changing the description to more precisely match the limited amount of what the spin currently does, or by changing the scope to match the fairly ambitious description. Also, without wielding the FESCo hat, at least to me that the discussion of philosophy and hierarchies is obscuring rather than clarifying the purpose and scale of the project. Mirek -- 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: [Guidelines change] Changes to the packaging guidelines
> Yes, that's the way I understand it too. The distinction between local > and remote is that remote attacks are in general more likely and thus > dangerous. > This is a good assumption - I'm sure that on most installations of Fedora > there's just one or a few trusted users, and they outnumber installations > with a large list of potentially rogue accounts. Note that with the recent-ish push towards having not-quite-trusted or even not-at-all-trusted applications running in local containers, local attacks over the network are more of a threat than in the past. (Not in the sense that running untrusted software locally any more of a threat with containers, but in the sense that we used to just say “don’t do that” and now some are promising that this is, or will be, safe.) Mirek -- 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: [Guidelines change] Changes to the packaging guidelines
Hello, > > Nevertheless, you raise an interesting question in general. The way > > I understand the motivation for the restriction is to avoid any > > chance of attack or unexpected access over the network. [...] > > OK, so the question is - are we (still) trying to preclude -local- > escalation-of-privileges type problems? Hopefully not just trying to: http://fedoraproject.org/wiki/Privilege_escalation_policy . I.e. there should be no known unrestricted privilege escalation paths. > If not, then many more > services can be enabled by default - as long as they bind only to > unix-domain sockets and/or localhost. As for restricted/authenticated privilege escalation: the default choice should be “switched off”, i.e. never install and enable a service just because someone wrote it if there is no actual need to keep it installed and enabled by default. (This is the case we’ve been burned with in the 1990’s—“Internet server” Linux distributions and UNIX products: package all available servers, install and enable all of them by default, they were supposedly either harmless or properly authenticated—except that the implementations, not the design intent, were insecure.) Obviously some services are much less, if at all, useful if not enabled by default, so this is obviously a balancing act; but I do want to stress that “services can be enabled by default” should be viewed more as a responsibility and a burden, rather than as a freedom to be celebrated and gleefully used to the maximum extent. > (I guess we're not supposed to > count on the default firewalls?) The firewall that allows most incoming connections on Workstation? No. Mirek -- 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 Self Contained Change: Netizen Spin
> On Mon, May 18, 2015 at 09:50:44AM -0600, Pete Travis wrote: > > A spin is a big effort with many interoperating packages and coordination > > with other teams (primarily releng, but you should also seek guidance from > > QA). It qualifies as a System Wide Change. > > Especially if this particular spin is asking for significant deviation > from our standard config (something I'm unclear about -- see Spins list > discussion). In that case, this definitely should be considered as > system-wide. On this particular procedural point, I think _all_ spins should be considered system-wide due to the required involvement of rel-eng, council and others; they are by no means “self-contained” in the sense that nobody else needs to help with getting them done. And generally I agree with the concern raised on the spins list (https://lists.fedoraproject.org/pipermail/spins/2015-May/004222.html and following) that the spin description can, at least by a quick read without reading the actual kickstart, likely to be misunderstood to deliver more than it actually does. For example, just including a tor package by no means guarantees privacy (e.g. it does nothing about all the ways Fedora leaks information about being Fedora). Mirek -- 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: Mono 4
> Now, is it our task as the change owners to update each and every > package that depends on Mono? > We have done a lot of preparation work, but would welcome the package > owners to review our changes to the spec files and import them into > their packages... > Does it work like that? Procedurally speaking, the https://fedoraproject.org/wiki/Changes/Mono_4#Scope section should clearly say what you are planning to do, and what you expect others to do. “Other developers: See Upgrade/compatibility impact and Dependencies section” is not exactly spelling it out but my reading is that you should be able to rely on the package owners taking care of their packages (but of course any help you can provide would be great). Mirek -- 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: ping6 and other tool6 awkwardness
> While working for an updated ipcalc to support ipv6 transparently, I > figured we have more tools which are not IPv6-ready and awkwardly > provide an additional tool with a -6 suffix, supposedly for separate > IPv6 support. That looks like a relic of the past, we still drag. IPv6 > support should be transparent in programs (fortunately we don't have > ssh6). Any objection to fill bugs to merge the following tools with > their ipv4 equivalent? It would be very desirable to modify the non-6 tools to have transparent IPv6 support. After that happens, I don’t think removing the -6 tools and possibly breaking scripts will really help anything; perhaps it would make sense to move them out of the default install, but doing any more work with the only possible effect something being broken is not that attractive ☺ Mirek -- 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: /usr/share vs /usr/libexec
> On Wed, Apr 22, 2015 at 8:06 AM, Miloslav Trmač wrote: > > Hello, > >> I confess I've only seen /usr/libexec used for add-on utilities, but > >> now I'm curious. > >> > >> Does it make more sense for these sort of scripts to live in > >> /usr/libexec, or in /usr/share? > > > > /usr/libexec. From (info standards): > > > >> `libexecdir' > >> The directory for installing executable programs to be run by other > >> programs rather than by users. > > > > The thing that threw me is that I poked around in /usr/share and found this: > > $ cat /bin/createrepo > #!/bin/sh > exec /usr/share/createrepo/genpkgmetadata.py "$@" > > Given what you're saying, would this be considered a bug in createrepo? Then we get into philosophical discussions about what is “the program” and what is “data used by the program”… In this case, the /usr/share/createrepo/* paths are not a documented stable API (but /usr/bin/createrepo is), and Python programs consisting of multiple files are easier to run and develop if all the files are in the same directory, so this seems a reasonable way to do things. Mirek -- 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: /usr/share vs /usr/libexec
Hello, > I confess I've only seen /usr/libexec used for add-on utilities, but > now I'm curious. > > Does it make more sense for these sort of scripts to live in > /usr/libexec, or in /usr/share? /usr/libexec. From (info standards): > `libexecdir' > The directory for installing executable programs to be run by other > programs rather than by users. vs. > Data files _used by the program during its execution_ (emphasis mine) starting the section that talks about */share Mirek -- 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: Time sync
> > Hello, > > > Besides gnome-control-center then, I guess the switch of > > > systemd-timedated to only supporting systemd-timesyncd > > > impacts FreeIPA too. > > > > Are you aware of > > https://lists.fedoraproject.org/pipermail/devel/2014-November/204658.html ? > > Yes, and I don't want to make changes to gnome-control-center that would only > be applicable to Fedora. The point of use timedatectl is that we don't have > to do a version for each distribution. Change timedated to do "the right > thing" > instead. AFAICT gnome-control-center is “fine” with timedatex used (well, working in Fedora; I’m not trying to solve upstream here). It just seemed to me that Colin’s original analysis (focusing on Atomic, not g-c-c) was not taking timedatex int account, and thus perhaps misleading (at the very least in the FreeIPA part, and thus perhaps for the other aspects of Atomic as well.) Mirek -- 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: Time sync
Hello, > Besides gnome-control-center then, I guess the switch of > systemd-timedated to only supporting systemd-timesyncd > impacts FreeIPA too. Are you aware of https://lists.fedoraproject.org/pipermail/devel/2014-November/204658.html ? Mirek -- 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: system-config-users and IPA
> I am writing patch for system-config-users that allows configure users ang > group from a IPA server with python library ipalib from package ipa-python. > I would like the changes be included in the system-config-users. What is the > best way to implement this from the point of view of architecture? I am now > implementing API that is similar to API of libuser. That would effectively mean that system-config-users contains an abstraction, which in one of the instances calls the libuser abstraction. It would seem more natural to write a libuser module instead of system-config-users- specific code—or, by far the best if possible, just use (or perhaps improve) libuser’s existing LDAP support. Longer-term, there is supposed to be a sssd-centric user management API, which would also replace/be called by libuser. I’m not sure what is the implementation status of this effort. Mirek -- 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-04-01)
=== #fedora-meeting: FESCO (2015-04-01) === Meeting started by mitr at 18:00:41 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-04-01/fesco.2015-04-01-18.00.log.html . Meeting summary --- * init process (mitr, 18:00:48) * #1384 F23 System Wide Change: Harden All Packages - https://fedoraproject.org/wiki/Changes/Harden_All_Packages (mitr, 18:03:23) * AGREED: Drop meeting keyword, continue tracking work in the ticket (+6) (mitr, 18:15:49) * #1416 F22 Changes - Progress at Change Checkpoint: Change Checkpoint: 100% Code Complete Deadline (mitr, 18:15:56) * LINK: https://fedorahosted.org/fesco/ticket/1416#comment:12 in particular (mitr, 18:16:22) * AGREED: 1) Ask Change owners to revisit the contingency plans and clarify (mitr, 18:38:16) * #1424 Clarifications to Change policy for changes which require rel-eng changes (mitr, 18:38:25) * AGREED: Clarifications approved (+7) (mitr, 18:40:46) * ACTION: jreznik will update policy process (mitr, 18:40:48) * #1426 Update freeze dates in the schedule (mitr, 18:42:46) * ACTION: jreznik to clarify that packages need to be in bodhi at 0:00 UTC on the freeze date (mitr, 18:45:44) * Next week's chair (mitr, 18:45:54) * nirik will chair next week’s meeting (mitr, 18:47:57) * Open Floor (mitr, 18:48:03) * LINK: https://bugzilla.redhat.com/showdependencytree.cgi?id=1156491&hide_resolved=1 (nirik, 18:53:30) * LINK: http://ghantoos.org/2008/09/28/yum-output-parser/ ... (drago01, 19:10:46) Meeting ended at 19:22:56 UTC. Action Items * jreznik will update policy process * jreznik to clarify that packages need to be in bodhi at 0:00 UTC on the freeze date Action Items, by person --- * jreznik * jreznik will update policy process * jreznik to clarify that packages need to be in bodhi at 0:00 UTC on the freeze date * **UNASSIGNED** * (none) People Present (lines said) --- * mitr (97) * nirik (83) * jwb (48) * rishi (37) * ajax (35) * sgallagh (31) * dgilmore (31) * adamw (22) * drago01 (19) * paragan (13) * jreznik (12) * zodbot (9) * mattdm (3) * roshi (3) * thozza (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
Re: "Your Outstanding Requests" on closed bugs
> Humans I can > understand having different views, but the tools should provide the humans > with > what we need here. In this case I think that means one of the following: > > 1) Require that the bot ignore bugs that are closed (assuming a majority > consensus agrees, which I understand isn't likely to happen) > > 2) Require that the bot be configurable by individuals to optionally ignore > (1) Surely the right thing is to not have any “unreviewed” patches in a closed bug by the time the bug is closed. (New unreviewed patches could arrive after the bug has been closed, same as new comments, but that is AFAICS not the situation prompting this thread.) Ignoring the inconsistent state of unreviewed patches in a closed bug is at best a band-aid. If we modify bugzilla at all, I would suggest to modify it as to resolve the review flags in patches while closing a bug (by marking them as reviewed, as refused, by dropping the review=? flags, or perhaps by saking). Mirek -- 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-04-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-04-01 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1384 F23 System Wide Change: Harden All Packages - https://fedoraproject.org/wiki/Changes/Harden_All_Packages .fesco 1384 https://fedorahosted.org/fesco/ticket/1384 #topic #1416 F22 Changes - Progress at Change Checkpoint: Change Checkpoint: 100% Code Complete Deadline .fesco 1416 https://fedorahosted.org/fesco/ticket/1416 = New business = #topic #1424 Clarifications to Change policy for changes which require rel-eng changes .fesco 1424 https://fedorahosted.org/fesco/ticket/1424 #topic #1426 Update freeze dates in the schedule .fesco 1426 https://fedorahosted.org/fesco/ticket/1426 = 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: Texlive packaging
Hello, > On Fri, Mar 27, 2015 at 08:28:21PM +0100, drago01 wrote: > > Actually "machine generated" isn't per se bad ... it saves a lot of > > effort and should be done more (for other packages too where > > possible). > > Why waste man power for something that can be automated? > > > > As for tex ... we could have a srpm for each one (machine generated > > there is no reason it has to be one srpm) would also mean that only > > the packages where something changes end up getting updated. > > Right, as I understand it, the gigantic single SRPM is to avoid the > normal requirement that each individual package have its own manual > review. For thousands of packages, that's quite a burden. > > But the workaround, while not violating any specific guidelines, > doesn't _really_ have any more careful individual review of each of its > parts — it's not a gain. And it has negative side-effects. > > If FPC would be open to bulk-approving machine-generated individual > spec files (given, say, they're provably all following the template, > which would be reviewed), and rel-eng has some way of bulk-adding the > necessary branches and builds, that really seems like a step forward to > me. > > Am I missing something? It is a general best practice to store the “actual source” (~preferred for of modification) in a versioning system, and not the generated results, e.g. to avoid manual edits to the generated files being lost on next regeneration. The current texlive texlive git repo does contain the generated texlive spec file, but it is IMHO much closer to the ideal than having thousands of individual repos with autogenerated spec files—either not having the template and generating tool in the git repo at all, pretty much guaranteeing drift from manual edits, or having a copy of the template and generating tool in each of the repos, making it very likely that the the template and tool will go out of sync. Ideally we would want the autogenerating tool in in a repo shared for all the packages (or perhaps just in a package required by redhat-rpm-config?), and then have no texlive*.spec files in git at all; this seems unlikely to happen soon. Failing this, the current arrangement seems by far the most maintainable alternative. Mirek -- 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: Disabled Repositories Support
> I wonder, are there any implications for dnf in terms of being consistent with > the new behavior of Gnome Software? Wait, the metadata download and search code is not shared? What would it take to make it so? /me wonders how many unicorns and kittens will have to die before we get rid of all this dupli^Wtriplication. Mirek -- 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 request to revert password confirmation change in F22
> I have no > clue why VNC passwords are limited/truncated to eight characters, but it > seems like that limitation makes the protocol not worth supporting at > all, let alone worth promoting in System Settings. The only VNC authentication mechanism standardized in RFC 6143 uses the password as a DES key, which limits it to 8 (7-bit) bytes. The VNC protocol can, however, support several different kinds of authentication, and several have been defined as vendor extensions. See e.g. http://sourceforge.net/p/tigervnc/code/HEAD/tree/rfbproto/rfbproto.rst#security-types . Restricting to non-standard authentication types, would, of course, impact interoperability. Mirek -- 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 Meeting Minutes (2015-03-04)
> Note that in upstream bug #735578 I have failed to build consensus on > any form of password strength checking, let alone the strict checking > that is done by libpwquality, so there is little chance at this point of > GNOME upstream adhering to any policy you come up with. The status quo > is that if libpwquality is in the PAM stack, as on Fedora, then > gnome-initial-setup is broken, and we will probably change > gnome-control-center to break as well (by not enforcing the password > strength check that PAM will enforce). (Ah, this is the mail I wanted to reply to, sorry. Just for the record, then:) Consider a client enrolled in AD/IPA. Then password policies are much more important than for a local-only account, and we _need_ gnome-control-center (and gnome-initial-setup if it can be used to change passwords or create IPA accounts) to enforce them. Perhaps the Workstation default configuration of libpwquality should be fairly lax, I don’t know, I haven’t looked in to this. But inappropriate default configuration is not a sufficient reason not to have enforcement in there. Mirek -- 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 request to revert password confirmation change in F22
Hello, > On Fri, 2015-03-06 at 12:00 -0700, Kevin Fenzi wrote: > > * The workstation folks think this change could drive away some of > > their potential users for not much gain. In their case, sshd is not > > enabled/running and additional security for a device that sits in > > your home isn't worth the additional complexity. > > Regarding Workstation: I don't think it provides any additional safety, > TBH. I see two cases: > > * Case 1: The attacker has physical access to your computer. > > * Case 2: The attacker doesn't have physical access to your computer. > The user account password is irrelevant. > My argument in Case 2 does fall down if the user enables SSH in the > Sharing panel of System Settings. That's indeed disabled by default, > though. It also falls down if the user enables VNC in the Sharing panel, > but that is an orthogonal issue as that's not your user account > password, and it's limited to eight characters regardless. There is another very important case where this falls down: the computer is enrolled into AD/IPA and the password is used throughout the organization. Just looking at a local machine does not necessarily tell you what the needed password strength is. This is of course not an argument in favor of making the policy stricter, but it does mean that _every_ way to change the password should respect the system-wide libpwsafe configuration. If the site administrator, along with enrolling into IPA/AD, sets up libpwquality to set up password strength restriction they deem appropriate, _all_ of Workstation should enforce these restrictions. Now perhaps the right default is to _have_ no restrictions but they need to be enforced the moment someone sets them up. > I mention it > because I hesitate to add a password strength check when enabling SSH > unless we do so for VNC as well, which would be impossible. Um, “we can’t do $this so we need to leave other parts of the system insecure” is really not sound logic. At the very least we have the option of giving up on VNC instead. And I don’t really see why it would be impossible to add a password strength check for VNC at all; in the worst case we could just store the libpwquality score when the password is set / changed somewhere, and use this stored score to decide whether to warn the user before enabling VNC (storing the scores like this, and telling the attacker which accounts are weak, would be bad on multi-user desktops, but those are rare nowadays and the admin wouldn’t want individual users to go enabling services on such machines anyway). What am I missing? Mirek -- 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 request to revert password confirmation change in F22
> On Fri, 2015-03-06 at 12:00 -0700, Kevin Fenzi wrote: > > * The workstation folks think this change could drive away some of > > their potential users for not much gain. In their case, sshd is not > > enabled/running and additional security for a device that sits in > > your home isn't worth the additional complexity. > > Regarding Workstation: I don't think it provides any additional safety, > TBH. I see two cases: > > * Case 1: The attacker has physical access to your computer. The user > account password is no protection: I think pretty much all of us know > how to boot a live image and copy files off the disk that way. A BIOS > password would actually help somewhat, to delay the attacker as long as > it takes the attacker to drain your battery to reset it. A disk > encryption password would be real security. No, the real security is actually the minimum of (disk encryption password)*fuzz, (user account/screen lock password); with a fuzz factor accounting for the fact that disk encryption password can be broken off-line, at full speed, farming it out to thousands of machines, but a screen lock password needs to be typed (or perhaps brute-forced using a keyboard-mimicking USB device, still slower than full speed, and restricted to one guess at a time). The way we deploy LUKS, a single password guess takes one second on a comparable hardware, so the fuzz factor is not actually as large as it might seem. The screen lock password still matters, though it does not need to be as strong as the disk encryption password. Mirek -- 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 request to revert password confirmation change in F22
Hello, > On Fri, Mar 06, 2015 at 09:43:33AM -0500, Adam Jackson wrote: > > As resolved by FESCO in our meeting on 4 March 2015, FESCO requests that > > anaconda revert a password behaviour change in the UI from F22, > > restoring the "double-click to confirm weak password" behaviour from F21 > > and earlier. > > From what I'm reading in the meeting logs and the ticket comments, it > appears the revert decision is basically a temporary solution and a more > formal security policy will be discussed later. We had technical arguments > in favor of the change originally, but I have yet to see technical arguments > against the change come together in any sort of concrete policy. There were quite a few use cases that just don’t warrant that strong a password, and where the insistence on a strong password is only annoying. Even if we completely discounted the Fedora testers, there are personal VMs, and there is Workstation with disabled ssh. Are these not “technical arguments against the change”? Sure, they are disconnected and don’t come packaged in a neat distribution-wide policy, but then neither does the anaconda change. Mirek -- 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 Meeting Minutes (2015-03-04)
> Adam Jackson wrote: > > * #1412 anaconda password change is causing consternation among the user > > community please review this policy decision (ajax, 18:24:10) > > * AGREED: FESCo would like anaconda to turn back on the "double-done" > > option for Fedora 22. > > Thanks! > > > Better solutions should be investigated for F23. (ajax, 18:43:33) > > What better solutions? What password I pick should be none of the > installer's business. > If the real issue is remote logins, then we need to just disable remote > password logins by default (i.e., allow SSH keys only by default). That is very much an option as part of the “better solutions”. > For local > logins, even the empty string is a reasonable password under some setups. (Well in that case it would be better not to prompt for the password at all, but I don’t think we are optimizing for this case that much ☺ ) Mirek -- 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: Legacy implementations of the Java platform in Fedora
> = Proposed System Wide Change: Legacy implementations of the Java platform in > Fedora = > https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora > > == Detailed Description == > This is no real work proposal. Stepping back, I’m not sure this has been said explicitly: this is really a packaging guideline proposal, not really a Change, so it should probably go through the FPC. (https://fedoraproject.org/wiki/Packaging_Committee?rd=Packaging:Committee#Guideline_Change_Procedure ) (This is not intended to kill or affect the implementation details discussion at all. I’m just trying to minimize the bureaucracy (hah!) by not setting a precedent for doing it this way, so that all future packaging guideline proposals go directly to the FPC and skip this redirection step.) Mirek -- 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: Legacy implementations of the Java platform in Fedora
> On 02/24/2015 06:41 PM, Miloslav Trmač wrote: > > Hello, > >> "java" would be the preferred JRE in Fedora. The package would have no > >> content, but it would have Requires on preferred Fedora JRE, currently > >> java-1.8.0-openjdk. This could be easily changed as default JRE changes. > >> The same is for other binary subpackages of "java", respectively. > >> > >> All system packages would require subpackages of "java" as they do now > >> (unless there is good reason not to). Users that install "java" would > >> get latest JRE, which would be updated to new major versions as they > >> become default. Older JDKs would not be removed during update (unless > >> there is no maintainer and they are obsoleted as currently), > > > > AFAIK nothing obsoletes a package just because it is orphaned… > > If no volunteer shows up for maintenance of old JDK then it would be > deprecated and obsoleted, as it's was done with previous JDK packages. How would that work _exactly_? 1. JDK-(N+1) is first shipped. The maintainer of JDK-N intends not to package it, so JDK-(N+1) includes Obsoletes:JDK-N from the start. 2. Someone revives JDK-N. Oops, it cannot be installed because JDK-(N+1) obsoletes it. 3. JDK-(N+1) is updated to remove the Obsoletes: . Oops, upgrades from older Fedora versions will no longer remove JDK-N for users who didn’t ask for the legacy version. This is the problem that the renaming to -legacy is supposed to prevent. Though, perhaps it would work equally well to have Obsoletes:JDK-N < $version-($release+1); this would still allow updating the older Fedora with bug fixes for JDK-N but to be removed on upgrade, as long as the $release number is kept low enough. And the possible -legacy package could then be represented simply by shipping a version with a bigger $release. Mirek -- 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: Legacy implementations of the Java platform in Fedora
Hello, > "java" would be the preferred JRE in Fedora. The package would have no > content, but it would have Requires on preferred Fedora JRE, currently > java-1.8.0-openjdk. This could be easily changed as default JRE changes. > The same is for other binary subpackages of "java", respectively. > > All system packages would require subpackages of "java" as they do now > (unless there is good reason not to). Users that install "java" would > get latest JRE, which would be updated to new major versions as they > become default. Older JDKs would not be removed during update (unless > there is no maintainer and they are obsoleted as currently), AFAIK nothing obsoletes a package just because it is orphaned… > but users > could remove them with "yum autoremove", unless something requires older > JDK or they installed it explicitly. … but most won’t run (yum autoremove). In effect, the vast majority of users upgrading from a previous Fedora version would end up with two JDKs installed, one of them an old, unmaintained RPM. Mirek -- 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: systemd-219 issues with 22 and Rawhide composes
> Communication is a two way street, and as an upstream I cannot be in > the business of pinging every single downstream about every single > change individually, in particular if I consider the change > unimportant. Sure, that makes sense. > To learn about changes upstream, please follow the upstream > discussions, thank you. However, this isn’t practical. The 1619! members of the packager group can’t be following every single upstream mailing list of every single project they depend on or they may be affected by. That is why we have http://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages , and why we _need_ that policy; it is not a gratuitous bureaucratic nonsense. Both systemd and Fedora would benefit if this communication were factored out like this, by having a Fedora liaison/“watcher” of systemd¹ that is primarily concerned with needs of Fedora and impact on Fedora. Mirek ¹ The Package maintainer responsibilities document places this on the package maintainers; but this would work equally well if anyone else did this, with or without commit rights to the systemd RPM. -- 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: recent/new Plasma5 crashes under investigation
> and now Qt(4) doesn't build either, bug, > https://bugzilla.redhat.com/show_bug.cgi?id=1192464 > > Any help, advice would be appreciated (particularly input from gcc > maintainers). > > > FESCo, work on the Plasma5 change/feature is suffering due to this. (Is this still applicable after the -no-use-gold-linker workaround?) Suffering in what way? Likely to have KDE 5 not perfect but still good enough to ship? Likely to have to revert to KDE 4? Likely to unable use KDE 5, and unable to revert because Qt 4 can not be rebuilt? Mirek -- 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: Firefox addon signing
> or simply exempt signature checking if > the extension is on disk. They should check on download only. That would defeat the entire purpose; malware is very commonly sideloading extensions. Mirek -- 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: Firefox addon signing
> On Thu, Feb 12, 2015 at 12:47:27PM +0100, drago01 wrote: > > A better way would be to add a "Fedora Signature" in addition to > > mozilla's and use that for packaged extensions. > > But that would require work on the build system (koji) side. > > The RPMs deploying the packaged extension are already signed and those > signatures are checked at time of package install. So it seems like > firefox merely needs to be taught that the pre-packaged extensions > deployed by RPM are pre-verified, so it can skip its verification > for those, while still doing verification for stuff that is live > downloaded Yes, that does seem like the most practical way and reasonably secure way to handle this; it might make Mozilla unhappy anyway. Firefox is really doing this to fight malware that has probably actually received (possibly unintended) permission from the user to install itself into the system, which often includes getting Administrator rights. So, to mirror that Mozilla intent exactly, even RPM-deployed extensions should require a Mozilla signature. OTOH, once you give malware root rights, it can in principle modify Firefox to skip the check, so this is only a hurdle, not a reliable feature. Equally, verifying the RPM extension contents against the RPM database and checking the RPM signature would be useless because the malware can just add its key to the keys RPM uses for verification. The Mozilla blog also mentions some “third option” for “extensions that will never be publicly distributed and will never leave an internal network”, presumably bypassing the need to have them signed by Mozilla. Could that be used by Fedora? Mirek -- 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-02-11)
Meeting started by mitr at 18:00:17 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-02-11/fesco.2015-02-11-18.00.log.html . Meeting summary --- * init process (mitr, 18:00:23) * Welcoming new FESCo members (mitr, 18:04:47) * ACTION: mitr to send a whenisgood form, results to be discussed on the next meeting (mitr, 18:07:17) * #1384 F23 System Wide Change: Harden all packages with position-independent code - https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code (mitr, 18:08:44) * LINK: https://fedorahosted.org/fesco/ticket/1384 (mitr, 18:08:48) * AGREED: F23 System Wide Change: Harden all packages with position-independent code approved (+5) (mitr, 18:11:39) * #1390 F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades - https://fedoraproject.org/wiki/Changes/RpmOstree (mitr, 18:13:25) * LINK: https://fedorahosted.org/fesco/ticket/1390 (mitr, 18:13:29) * #1396 F22 System Wide Change: Atomic Host - https://fedoraproject.org/wiki/Changes/AtomicHost (mitr, 18:13:31) * LINK: https://fedorahosted.org/fesco/ticket/1396 (mitr, 18:13:35) * #1397 F22 System Wide Change: Bare Metal Installer for Fedora Atomic Host - https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic (mitr, 18:13:40) * LINK: https://fedorahosted.org/fesco/ticket/1397 (mitr, 18:13:44) * AGREED: Defer tickets 1390, 1396, 1397 until we get more specifics, remove meeting keyword until then (+6) (mitr, 18:15:17) * #1392 Review scope of "Python 3 as default" Change for F22 (mitr, 18:15:31) * LINK: https://fedorahosted.org/fesco/ticket/1392 (mitr, 18:15:35) * AGREED: Close this ticket, discuss the specifics in #1413 instead. (+5) (mitr, 18:18:27) * #1413 F22 System Wide Change: Python 3 Migration Improvements - https://fedoraproject.org/wiki/Changes/Python_3_Migration_Improvements (mitr, 18:18:44) * LINK: https://fedorahosted.org/fesco/ticket/1413 (mitr, 18:18:48) * AGREED: F22 System Wide Change: Python 3 Migration Improvements has been accepted (+6) (mitr, 18:21:11) * #1406 F22 System Wide Change: Systemd Package Split - https://fedoraproject.org/wiki/Changes/SystemdPackageSplit (mitr, 18:21:20) * LINK: https://fedorahosted.org/fesco/ticket/1406 (mitr, 18:21:24) * No conclusion reached (+3 -1 1×0), will discuss next week (mitr, 18:40:02) * #1377 enable kdump addon by default (mitr, 18:40:11) * LINK: https://fedorahosted.org/fesco/ticket/1377 (mitr, 18:40:15) * AGREED: Enabling the kdump addon by default was rejected (-5) (mitr, 18:49:52) * #1408 New package/branch request processes (off bugzilla to pkgdb) (mitr, 18:50:04) * LINK: https://fedorahosted.org/fesco/ticket/1408 (mitr, 18:50:08) * AGREED: Implement a similar waiting period for Fedora branch as we do for EPEL branch (+5) (mitr, 18:55:13) * #1409 provenpackager request: mstuchli (mitr, 18:55:28) * LINK: https://fedorahosted.org/fesco/ticket/1409 (mitr, 18:55:32) * AGREED: Change http://fedoraproject.org/wiki/Provenpackager_policy step 4, s/In case of negative votes/If you haven’t been automatically approved/ (+5) (mitr, 19:02:48) * #1410 Updates Policy should try harder to prevent updates that break future updates (mitr, 19:03:02) * LINK: https://fedorahosted.org/fesco/ticket/1410 (mitr, 19:03:06) * AGREED: Increasing the time spent in testing was rejected (-5) (mitr, 19:06:37) * AGREED: Replacing gnome-packagekit by gnome-software in critical path definition has been approved (+5) (mitr, 19:09:17) * AGREED: 1) Ask librepo maintainer to test off-line updates before pushing any updates. 2) Recommend gnome-software maintainers to write automated tests for their update mechanism (+6) (mitr, 19:18:13) * #1411 F21 privacy issue, Geolocation done for every install (mitr, 19:18:15) * LINK: https://fedorahosted.org/fesco/ticket/1411 (mitr, 19:18:19) * AGREED: Cc: spot for fedora-legal to see whether there is any issue or whether we need to update privacy policy (+5) (mitr, 19:34:37) * #1269 Closing all 'Merge Review' bugs (mitr, 19:34:47) * LINK: https://fedorahosted.org/fesco/ticket/1269 (mitr, 19:34:51) * AGREED: Reassign all merge reviews to their component, version=rawhide, with the comment in https://fedorahosted.org/fesco/ticket/1269#comment:16 (+5-1) (mitr, 19:40:38) * ACTION: crobinso to mass-edit and reassign the bugs (mitr, 19:41:19) * #1326 change to fesco replacement process? (mitr, 19:41:28) * LINK: https://fedorahosted.org/fesco/ticket/1326 (mitr, 19:41:32) * deferred (mitr, 19:44:53) * Next week's chair (mitr, 19:45:57) * jwb will chair next week’s meeting (mitr, 19:46:41) * Open Floor (mitr, 19:46:46) Meeting ended at 19:49:24 UTC. Action Items * mitr to send a whenisgood form, results to be discussed on the ne
Re: Schedule for Wednesday's FESCo Meeting (2015-02-11)
> On Tue, Feb 10, 2015 at 11:08 AM, Miloslav Trmač 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-02-11 18:00 UTC' > > > > > > Links to all tickets below can be found at: > > https://fedorahosted.org/fesco/report/9 > > Whew... this is a rather large list. I'm somewhat doubtful we're > going to get through all of this even in 2 hours. Do we want to > prioritize the order a bit? Once you account for closely related tickets and the provenpackager request which seems to have been resolved in the meantime, it’s “only” 10 items. That’s still quite a few especially considering this is a new FESCo, I’ll move the long-unresolved items that aren’t urgent for F22, i.e. #topic #1269 Closing all 'Merge Review' bugs #topic #1326 change to fesco replacement process? to the end of the list if there are no objections. Mirek -- 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-02-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-02-11 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 #topic Welcoming new FESCo members = Followups = #topic #1269 Closing all 'Merge Review' bugs .fesco 1269 https://fedorahosted.org/fesco/ticket/1269 #topic #1326 change to fesco replacement process? .fesco 1326 https://fedorahosted.org/fesco/ticket/1326 #topic #1384 F23 System Wide Change: Harden all packages with position-independent code - https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code .fesco 1384 https://fedorahosted.org/fesco/ticket/1384 #topic #1390 F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades - https://fedoraproject.org/wiki/Changes/RpmOstree .fesco 1390 https://fedorahosted.org/fesco/ticket/1390 #topic #1396 F22 System Wide Change: Atomic Host - https://fedoraproject.org/wiki/Changes/AtomicHost .fesco 1396 https://fedorahosted.org/fesco/ticket/1396 #topic #1397 F22 System Wide Change: Bare Metal Installer for Fedora Atomic Host - https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic .fesco 1397 https://fedorahosted.org/fesco/ticket/1397 #topic #1392 Review scope of "Python 3 as default" Change for F22 .fesco 1392 https://fedorahosted.org/fesco/ticket/1392 #topic #1413 F22 System Wide Change: Python 3 Migration Improvements - https://fedoraproject.org/wiki/Changes/Python_3_Migration_Improvements .fesco 1413 https://fedorahosted.org/fesco/ticket/1413 #topic #1406 F22 System Wide Change: Systemd Package Split - https://fedoraproject.org/wiki/Changes/SystemdPackageSplit .fesco 1406 https://fedorahosted.org/fesco/ticket/1406 = New business = #topic #1377 enable kdump addon by default .fesco 1377 https://fedorahosted.org/fesco/ticket/1377 #topic #1408 New package/branch request processes (off bugzilla to pkgdb) .fesco 1408 https://fedorahosted.org/fesco/ticket/1408 #topic #1409 provenpackager request: mstuchli .fesco 1409 https://fedorahosted.org/fesco/ticket/1409 #topic #1410 Updates Policy should try harder to prevent updates that break future updates .fesco 1410 https://fedorahosted.org/fesco/ticket/1410 #topic #1411 F21 privacy issue, Geolocation done for every install .fesco 1411 https://fedorahosted.org/fesco/ticket/1411 #topic Meeting time = 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: mongodb.conf rename
Hello, > in Fedora Rawhide there is a new major version of mongoDB 2.6. With this > new version names of mongoDB configuration files will be changed - to > reflect names used in upstream rpms > (http://downloads-distro.mongodb.org/repo/redhat/os/x86_64/RPMS/ ) > > mongodb.conf -> mongod.conf > mongodb-shard.conf -> mongos.conf > > In Fedora mongodb.conf is used from version 12. > > If this change should be a problem, please contact me... Is it possible to do something (write RPM scriptlets, or perhaps ship symlinks) to make this transparent and effortless to users? Mirek -- 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: on software updates
> On 31 January 2015 at 21:57, Casey Jao wrote: > > Are there any plans to let packages specify that they do not require a > > total > > system reboot to be updated? > > Yes, see https://wiki.gnome.org/Projects/SandboxedApps -- basically, > you can't do updates of rpm-sourced system-wide app deployments > without a reboot in a safe way. There are classes of RPMs that definitely can be done without a reboot in a safe way (documentation-only; packages with a single executable and no libraries / separate data files; and quite a few other cases), and letting packagers opt them in to being updated without a reboot seems like a clear improvement on the status quo. I don’t know, perhaps they are currently rare enough that it is not worth it; but it seems to me that we will need vaguely that kind of infrastructure in any case (if only to allow updates of the sandboxed apps). Mirek -- 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: Filing Bugs for Python 3 Switch
(Speaking only for myself, not for all of FESCo; hoping others will chime in.) > - What if Anaconda does make it? :) I don’t know. > - What is "enough"? It's possible that two or three packages may be still > unported even in F23 (and as for server livecd in F23, I think there will be > few more). 2-3 packages should not be an issue, perhaps unless they were very visible (e.g. having a public and widely-used Python plugin API). > - So is it ok if I file bugs for all components that I know are > upstream-compatible with Python 3 (bugs to get them switched, I mean)? If we are shipping both Python versions anyway, and the specific packages are known to be compatible (i.e. there little risk), I don’t see any reason not to switch them already in F22. Mirek -- 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: Filing Bugs for Python 3 Switch
> > So, at today's FESCo meeting there was a good deal of discussion about > > python as default: > > http://meetbot.fedoraproject.org/fedora-meeting/2015-01-28/fesco.2015-01-28-18.02.log.html#l-41 > > > > in which we agreed defer this to F23, file bugs against rawhide after > > branch (+6,0,0) > > I really don't get this. I was over the log and didn't find a compelling > argument as to why this should be postponed. Can someone sum the arguments > up, please? Let me try, based on my understanding of the conversation: whatever the technical changes / progress in migration are (and the actual migration can of course technically be staged over time), we can only have a public announcement (and PR) that “Python 3 is now the default” once. We do have some flexibility in what that announcement means, but it should be enough so that we will never need to follow up with a “Python 3 is now really the default, trust us this time” Change/announcement. FESCo felt that not “enough” has been ported yet (in particular that the default install will not be ported by F22, and that Anaconda is unlikely to make it), hence postponing the Change / announcement aspct. Mirek -- 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: Plan of Record for Fedora 22 Network Install Media
> On Fri, Jan 23, 2015 at 2:24 PM, Stephen Gallagher > My first question is "why do there need to be four branded network > install releases?" If they're all capable of making a workstation, > server, cloud image or generic Fedora, why not just have *one* network > install release and a more user-friendly menu for choosing the package > groups / packages? Technically, it does seem possible in principle to have the partitioning layout defaults encoded as a new filed in the the environment group in comps so that a single anaconda image could install any of the products using the respective preferred configuration. Of course, “does seem possible in principle” is not a replacement for actually getting code written… Mirek -- 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: DNF replacing yum: fedup?
> There is in fact no strict *technical* requirement for anything to > move from yum to dnf in F22. yum will remain in the F22 package set, > it is not being removed. > > However, the Change seems to me to have been written with the basic > idea that yum shouldn't be installed by default any more and nothing > that's a core part of Fedora should use it any more - for e.g., the > Change incorporates moving anaconda to dnf, even though technically > speaking there's no *need* for this, we could if we wanted to ship F22 > with anaconda using yum but the installed system using dnf. > > So given that, I wanted to clarify the status of fedup. > > If F22's fedup depends on yum, then people with 'clean' dnf-only > systems are going to get yum installed when they want to upgrade to > F23. Aren’t there cases where yum and dnf resolve ambiguous dependencies differently? If so, anaconda-installed and fedup-installed systems may end up with different packages, which seems fairly undesirable. I suppose as long as fedup is part of the release criteria and get tested there shouldn’t be huge surprises, but using the same mechanism for all of (anaconda, fedup, post-install CLI, post-install GUI) seems like the ideal we should be aiming for, not as an aesthetics matter but as a “technical requirement” to minimize the testing matrix (for both individual packagers and distribution-wide QA). Mirek -- 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: GUI applications writing garbage to stdout/stderr
> On 01/27/2015 07:03 AM, Bastien Nocera wrote: > > All those are warnings, not "garbage" or debug output. File bugs about > > those, > > there should be zero warnings in normal usage. > > Shouldn't they trigger abrt then? Yes, that would be a great help towards making the warnings filed and fixed. Care to file a RFE against abrt and/or the libraries that output the warnings? Mirek -- 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: initscripts
> and the main point is: there is no need to replace network.service on > *any* static configured machine (As a short-time initscripts comaintainer way-back-when:) There may not be a need for anything smarter than init.d/network for machines with _trivial_ static configuration (a few interfaces with static IP addresses), but it starts breaking down very quickly with more complex setups. Networking is inherently a DAG: IP alias ON TOP OF a bond ON TOP OF an Ethernet vlan ON TOP OF a vlan trunk connected through a physical cabe¹, and frequently when something changes in this DAG (change an IP alias, change bond composition, change vlan tag, change a performance tuning parameter) it would be useful to also update/refresh configuration of the other related components. And building the kind of data structure necessary to keep track of these relationships is pretty much impossible in the shell language², so it hasn’t been done. init.d/network more or less assumes that the complex cases don’t happen instead of supporting them properly. Mirek ¹ This may be a nonsensical example, it’s been about 8 years. But I am confident about the gist of the issue. ² Well, after seeing ifup-aliases, my sense of what is “pretty much impossible in the shell language” has been dulled; but maintaining such relationships is another order of magnitude more complex than ifup-aliases, and given the speed of shell a shell daemon (☺) would be needed anyway just to amortize the overhead of dealing with the DAG. -- 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: Atomic Host
Hello, > == Scope == > * Other developers: Unknown. > * Policies and guidelines: May need updates for RpmOstree. This is too vague. What basis do have the other developers for commenting about how they would be affected, knowing only the above? > == Detailed Description == > The original Changes/Atomic_Cloud_Image was a host system delivered just as a > cloud image. This Change for Fedora 22 expands it to a multitude of delivery > vehicles: OK, “expands… delivery vehicles”. > == Contingency Plan == > If something fails and this product can't ship, some upgrade mechanism for > Fedora 21 Atomic Cloud Image users would need to be evaluated. How is this related to “expanding… delivery vehicles” as described above? The F21 cloud image is the original delivery vehicle, not one of the expanded ones. Is this a copy&paste from one of the other Change proposals, or a missing part in the Detailed Description? Mirek -- 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: Django 1.8
Hello, > ** A build containing latest Django will be pushed to f22 branch late in dev > cycle. If we decide not to push Django-1.8, nothing will be broken. > ** Django 1.8 final release is expected around April 1st, 2015: [2] Note that the “Change checkpoint: completion deadline (testable)” is on Feb 24; do you plan to have a beta version built by then? Mirek -- 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: amending the new package process
> On Thu, 2015-01-22 at 09:57 -0500, Miloslav Trmač wrote: > > > That's good for you, but unacceptable to me. That way we penalize people > > > who add packages. > > Penalize in what sense? > > In the sense, that in addition to packaging something new you have to > review something else in order to get your new package in. If reviewing > is voluntary it should affect every packager the same, not just the ones > who bring new packages. That’s nice in theory but just doesn’t work; everyone “should" be reviewing packages or else what? The current solution has two advantages, 1) most importantly, it actually (mostly) works, unlike saying “please review packages thank you” 2) it is vaguely fair in the sense that who drains the pool of available reviewers is also required to resupply it. > I am not against reviews, I'm against something I see it doesn't work. It is true enough that this doesn’t work well for _new_ contributors, yes. For already sponsored packagers that can get their package reviewed by swapping a review, I don’t currently think this is a particularly big problem. > Otherwise we are keeping quality by avoiding anything new. (Well that is actually a valid choice to make if it is made consciously ☺) I do agree that we seem to be overshooting with the packaging quality, but how can we actually improve things? I don’t think the proposal of "wait 2 months then auto-approve” will make much difference for the new/inexperienced/impatient newcomers. Mirek -- 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: Tunir
Hello, > Tunir is a self contained CI Continuous Integration [1] which will be used to > test Fedora Cloud images nightly. What relationship, if any, does this have with Taskotron? Do I understand correctly that this Change does not involve / require setting up automated test runs by rel-eng or Fedora infrastructure? Mirek -- 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: amending the new package process
> On Wed, 2015-01-21 at 12:10 +0100, Vít Ondruch wrote:
> > > I'd like to propose an amendment to allow
> > > bringing packages even if no reviewers are available (the typical case).
> > >
> > > Step 6: ... If the proposed package is not reviewed for 2 months, the
> > > package must be reviewed by the submitter, and a git module with the
> > > master branch will be approved.
> > The self review doesn't make sense, since I expect you did the package
> > to your best knowledge already and you really want second pair of eyes
> > to find any issues which slipped through your hands.
> > At least myself, I always looking for reviewer who cares to find every
> > issues I missed, challenge my knowledge and I'd be quite unhappy to
> > discover later that something slipped through review unnoticed.
>
> That's wishful thinking. I proposed that rule in order to make apparent
> the fact that there are not enough reviewers and new packages are
> blocked in the queue. Ignoring the fact isn't going to make it go away.
True, there are not enough _voluntary_ reviewers. But review swaps generally
seem to work, or don’t they in your experience?
> > And there is nothing wrong with review swaps. You help others, they help
> > you.
>
> That's good for you, but unacceptable to me. That way we penalize people
> who add packages.
Penalize in what sense? It is unavoidable that when reviews are mandatory,
overall the project’s contributors need to do as many reviews as new code
additions. That’s not a penalty for anything, it is just a task, or, to put it
another way, Fedora’s choice of desired packaging quality level.
As to whether this quality level is warranted and those reviews are necessary,
unfortunately, with the current packaging mechanisms, it probably is; because
there are quite a few ways to screw up or to take shortcuts, and people who
want to primarily focus on application source code instead of packaging tend to
take these shortcuts at most opportunities (and historically Red Hat employees
have been the sources of most of the most egregious shortcuts or worse).¹
Ideally, most of the guidelines, and thus the reviews, shouldn’t _exist_: we
should have software either implementing the packaging functionality so that
the easiest shortcut is to do it correctly, or at least software doing
automated reviews. But that just isn’t happening; apparently we have enough
volunteers interested in writing and approving guidelines, but enough
volunteers interested in writing the code to make the guidelines go away.²
Mirek
¹ Admittedly it is inconsistent that the _only_ thing in the project which
requires an independent review is packaging, and only the initial packaging at
that. OTOH there are plausible {reasons,excuses} for that: getting qualified
independent reviewers for non-packaging code would be so difficult to make it
not worth it, and once a packaging happens correctly it tends to stay correct
because exactly the people inclined to take shortcuts are not likely to touch
it if they don’t have to.
² Though, fedora-review exists, and hasn’t AFAICT replaced any item in the
guidelines; so it is very well possible I am missing a part of the story.
--
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: Testers needed: KDE kcm_touchpad libinput support
> Please add this copr > https://copr.fedoraproject.org/coprs/whot/kcm_touchpad/ > > Please review this branch: > https://github.com/whot/kcm_touchpad/tree/wip/libinput-support Thanks for taking on this additional work. Mirek -- 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: Database Server Role
> == Scope == > * Release engineering: > ** Pre-loading roles will need to be a capability of the Anaconda install > system, both in the graphical installer and kickstart While this functionality is desirable, it seems not to be directly related to the database server. Mirek -- 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: Set sshd(8) PermitRootLogin=no
> On Fri, 2015-01-16 at 15:39 +0100, Lubomir Rintel wrote: > > > > There's a chance of a successful exploitation that would result in > > obtaining my privileges. Sure, gaining access to my account is bad > > enough, but if I run "su" or "sudo", they have root! > > Along these lines, someone pointed out a rather nasty attack vector > via sudo the other day: > > http://blog.grdryn.me/blog/fedora/prank-alias-sudo-in-bash.html > > so...you'd better remember to call it with \ every time...:) This is a „movie plot threat“, proposing a specific attack and a specific mitigation, but doing nothing about the immediately available alternative attacks. For example, I could edit ~/.profile to replace the running bash with a modified copy that ignores (or even specifically hijacks) the \ in \sudo. At a first glance it seems to me there in principle can’t be a way to protect against a modified shell environment from within that environment because that environment can lie to you about any system output, or to the system about any your input. (So even having a trusted “antivirus service” running outside of the shell and protected against it wouldn’t be useful because from the shell you could never be sure that you are talking to that trusted service.¹) Mirek ¹ Well, establish a TLS channel through the malicious shell directly to the antivirus… Just no. -- 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: RpmOstree - Server side composes and atomic upgrades
> On Tue, Jan 13, 2015, at 04:41 PM, Colin Walters wrote: > > > If it's installing a regular file, then it won't work - the package > > (daemon) needs to create it on start. > > I filed a bug about this: > > https://bugzilla.redhat.com/show_bug.cgi?id=1182785 > > Though I wonder if this should be a Change in itself, or a packaging > guideline update? I think it does need to go through the FPC. I don’t see a benefit in splitting the Change into two if there is a strict dependency; would it make sense to have the /var change without the rest of the RpmOstree features, or vice versa? > To be clear, this transition doesn't have to happen all at once, only for the > packages that > one would want to consume via rpm-ostree. (Which ideally at some point is > all, but > I'm focusing on the core personally) (FWIW the schedule for going through the FPC and hitting the completion/testable deadline on Feb 24 feels a little tight, though probably still doable. Do you know how many packages would be affected?) Mirek -- 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: Set sshd(8) PermitRootLogin=no
> On Wed, 14 Jan 2015 12:34:22 -0500 (EST) > Miloslav Trmač wrote: > > > > On Wed, 14 Jan 2015 16:54:09 + (UTC) > > > P J P wrote: > > > > I'd request all(those who are opposing) too describe their > > > > requirements in the etherpad page above. > > > > > > Being able to authenticate as root right after installation would be > > > the requirement for me. > > > > Let’s be precise here; “able to authenticate as root” is an > > implementation detail; the underlying requirement is something else. > > “Able to set up IPA”? “Able to run administrative commands in > > shell?” (e.g. we could just, as a part of firstboot, open a root > > shell without any authentication ☺ ). Mirek > > except that will not work when you do not have access to a console and > only have ssh access At this point/in this sub-discussion, I personally very much don’t care. Let’s collect the requirements first. Mirek -- 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: GCC5
> * Contingency mechanism: Revert to older gcc, mass rebuild everything again > * Contingency deadline: Before release This is an invasive contingency mechanism, requiring retesting a lot of functionality; the contingency deadline for this (i.e. when we need to be comfortable that the revert will not be needed, should certainly be at the usual beta freeze at the latest, if not earlier. Invoking this contingency mechanism “before release”, say during the GA RC phase, would really not be feasible without a massive slip. Mirek -- 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: GCC5
> On Wed, Jan 14, 2015 at 02:24:29PM +, Peter Robinson wrote: > > I was thinking exactly that, mass rebuild is scheduled for Jan 30th > > according to the schedule [1] with branching 10 days or so later. That > > is only two weeks away. With statements like "The release will happen > > probably in the first half of April" when we're already suppose to be > > be in freeze from end of March I think this would be better landing in > > F-23 right after we branch F-22 off on Feb 10th. Ultimately the above > > gives us no room to move and a roll back is another mass rebuild which > > will only cause more delay! > > Again, how is that different from F9, F11, F13, F15, F17, F19? We are learning not to do the same mistakes all over again ☺ Now it could, I guess, be argued, that gcc has a long history of not having egregious failure modes we are learning from, and should be allowed to land later. OTOH there is also, IIRC, a history of having to do a second (full or partial) or even a third rebuild due to necessary gcc bug fixes, and landing the .0 version at the time we ship Beta is basically an explicit bet that there will be no such bug in .0, or we are slipping. Mirek -- 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: Set sshd(8) PermitRootLogin=no
> On Wed, 14 Jan 2015 16:54:09 + (UTC) > P J P wrote: > > > On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote: > > > Ok, I state my opposition to without-password too inequivocably > > > here. Mostly because it is just the same as 'no', given there is no > > > way, in a regular install to seed a key into the root account. > > > > > > Except you have no mechanism to inject a key at installation time, > > > >Sure. Could you please elaborate how would you like this key to be > > injected into the 'root' account? Feature page does have a listed > > workflow change: > > > > "Anaconda installer OR maybe OpenSSH package needs to create > >initial set of authentication keys for 'root' user." That’s not how, to my knowledge, ssh keys are usually deployed; there is one private key per user (or, for the paranoid, one private key per client machine / user’s home directory), not one private key per the server one is connecting to. And creating a key does not really solve the problem: how do the administrators get the key so that they can connect? > > I'd request all(those who are opposing) too describe their > > requirements in the etherpad page above. > > Being able to authenticate as root right after installation would be > the requirement for me. Let’s be precise here; “able to authenticate as root” is an implementation detail; the underlying requirement is something else. “Able to set up IPA”? “Able to run administrative commands in shell?” (e.g. we could just, as a part of firstboot, open a root shell without any authentication ☺ ). Mirek -- 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: Remove gcc, gcc-c++ and make from minimal build root
> Dne 13.1.2015 v 08:12 Ralf Corsepius napsal(a): > > On 01/13/2015 07:12 AM, Stanislav Ochotnicky wrote: > >> On Tue 13 Jan 2015 01:35:26 AM CET Kevin Kofler wrote: > >>> Vít Ondruch wrote: > > I basically see several issues: > > > > 1. The sheer amount of packages being affect. By all accounts we are talking an order of thousands of packages, i.e. thousands of hours spent on adjusting the BuildRequires. Conservatively, that could have been hundreds of user-visible bugs fixed; why is the user-invisible, and often developer-invisible, build speedup worth these hundreds of bugs? > > 3. There likely are many tiny problems under the hood (esp. in > > packages primarily written in scripted languages), such as (yet > > unknown and hidden) conditionally built > > features/sub-components/sub-packages and conditional deps etc. > > Definitely, something will bite us. Nobody claims the opposite. Nobody > says its piece of cake, lets do it for F22. Looking at this in reverse, if we had the option to save thousands of hours and avoid unknown regressions by spending 20 seconds extra per build, why yes, we would very likely take it. So shouldn’t we, consistently, not spend those thousands of hours and a risk of “definitely something will bite us” to save 20 seconds per build? Don’t get me wrong, speeding up builds is good in principle; but we have to consider the opportunity cost. Couldn’t we find a way to completely automate away this decision so that the builds are fast and the packagers don’t have to care? Mirek -- 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: Remove gcc, gcc-c++ and make from minimal build root
> On Tue 13 Jan 2015 01:35:26 AM CET Kevin Kofler wrote: > > I actually think that cmake should be added to the minimal build root, > > instead of removing stuff. Almost all the packages I work on BuildRequire > > cmake (which also implies that they need make to build, and gcc-c++ is the > > typical implementation language). > > Yes good idea. I worked on Java packages. Let's put Maven in minimal > buildroot. I am sure everyone will enjoy it. And, you know, why not, exactly? It’s not like the minimal buildroot is a cloud image where every megabyte is multiplied by hundreds of thousands of users and costs money. Rather, the inevitable series of dozens of (yum install $library-devel) every developer does after installing a new OS is much more of a hassle than a few hundred megabytes of space used by default. Yes, let’s agree (hah!) on good, stable, well-designed programming languages and libraries, and then install them by default in both the Workstation default install and the default build root.¹ > Seriously though what's a problem with listing your package's real build > requires? Life is too short to spend time micromanaging things that don’t actually matter for improving utility of the resulting applications to users. Micromanaging the dependencies is not inherent to solving any application use case; it is purely accidental complexity / pointless hassle. Lidem myšlení—strojům dřinu!² (Incidentally, this would be much less of a problem if we had a way to add all the needed BuildRequires: automatically, and actually did that. But the mere presence of these BuildRequires: in spec files would still be accidental complexity we are introducing into packaging—or alternatively, if we had a tool to detect this dependency then we wouldn’t need to explicitly list the dependency in the spec file.) Mirek ¹ Now I am not saying that C/C++/make are that great that they would now warrant being chosen for to the default set but they are so prevalent that if there is any default set it has to include them. ² Let people think and machines toil. -- 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: RpmOstree - Server side composes and atomic upgrades
> == Scope == > * Other developers: > *** Use systemd-tmpfiles instead of placing content in /var (TODO: better > docs > for this) Is this a strict dependency or a nice-to-have item? That is, are we talking about having to change all such packages in Fedora (or some specific subset) within the next ~month? Mirek -- 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: RpmOstree - Server side composes and atomic upgrades
> Jaroslav, there is a lot more information on the actual wiki page. > Like the fact that this is only for particular opt-in new installs and > that yum/dnf/RPM can only operate in read-only mode on such installs. > Could you resend this with the entirety of the text? It might lead to > fewer questions. This is being sent to devel-announce, so should not overwhelm people who are not interested. That’s why it includes the basic description (to let you decide whether you are interested) and the Scope section (to let you check whether this will, through the “Other developers” bullet point, place demands on you). It is somewhat important that everybody reads these parts; wouldn’t including the full page drown these parts out? Mirek -- 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: Set sshd(8) PermitRootLogin=no
> > - improves accountability for administrative actions (we know which admin > > messed up :) > > Nonsense. for non-malicious logins, sudo leaves as much as a trail as > sshd which tells you which credentials were used to login. For malicious > logins, once root access is obtained via password-less sudo, the > evidence is removed from the logs. … which is why good large-scale setups immediately send logs away from the machine to a dedicated log host. True, given our current design, which does not block the log in on successful log write/flush, this becomes a race between sending the logs and the attacker logging in and trying to abort the log sending operation. Also I realize that many (single-user and small data center) setups do not have such a log host; still, the OS should be designed to make such auditing at least possible, and making it easy enough to eliminate direct logins to the root account (whether using a password or a key) would go in that direction. Mirek -- 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: Set sshd(8) PermitRootLogin=no
> - The 'method' used to restrict remote root access is negotiable. Ie. disable > it completely by setting PermitRootLogin=no OR disable remote root login > via password by setting PermitRootLogin=without-password. (The general theme of this mail: Being flexible is fine, and establishing this through this discussion is great; however, ultimately the Change proposal needs to document the _specific outcome_ of that discussion.²) > - Major concern so far is how this feature could break existing workflows. > That is genuine and can be addressed adequately. “Can be” or “will be”? How? It is vaguely worrying that the Change proposal explicitly lists only the most trivial task to do (change a sshd.conf option) and is only fairly generic about how other parts of the OS and users need to and/or will adapt. > PermitRootLogin=no > * If we disable remote 'root' access, non-root user access becomes > imperative. > - Anaconda & cloud_init tools already facilitate creation of non-root user > accounts. > - Creation of one non-root account could be made mandatory. > - Omission of non-root account creation could show discretionary warning. > - Omission of such user account creation could conditionally enable remote > root access. “Could conditionally“… With my FESCo hat on, during the Change Checkpoints FESCo will need to know whether the Change is sufficiently complete or whether to fall back to the contingency plan. Having a “Could conditionally” nailed down to yes or no would prevent general unhappiness if the respective package maintainers thought that they have done the right thing and FESCo during review suddenly decided that the right thing is the opposite. Separately from the general theme above, > - Second tune is that the feature does not add any security. That is like > saying having a security guard at the entrance adds no value, because > atrocities still continue to happen around us. The requirement to know a user name, which is in most cases just an automatable task¹ nobody is trying to prevent or make harder, is not really the same as a requirement to bypass a security mechanism (subdue a guard or guess a password). It’s been about 10 years already since I have witnessed an automated password guessing bot carrying a list of user names and real names from previously infected systems as a “crib sheet” for guessing on new systems; this is not a hypothetical thing that bot authors are too dumb or lazy to do. So this proposal only helps if we hope that a bot won’t try the right user name; calling this security by obscurity is not too wide off the mark. Mirek -- 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: Harden all packages with position-independent code
> That said, even on x86_64 it isn't anything close to no overhead. > Tried last night to rebuild GCC's cc1plus as -fpie -pie, and then > rebuild stage3 of GCC with make -j1 separately with the original stage3 > cc1plus (ET_EXEC binary) and PIE cc1plus (ET_DYN). The build (which > included still time for various other tools being not PIE, make, ld, as) > got 2.1% slower user time. Thanks, this would probably be the first significant example of a really affected program: ( https://fedorahosted.org/fesco/ticket/1113#comment:9 ) 1. Built in the distribution 2. CPU-bound (or CPU-limited in the primary performance metric) 3. Not required use PIE already (= not running as root, not a daemon) 4. (added): Not having the CPU-bound part in a shared library, like firefox or libreoffice¹ do. How many other such programs are there? If all we are talking about is increased program build times, that is IMHO _well_ worth the security mitigations. Mirek ¹ (Both Firefox and LibreOffice are disqualified through 3. anyway.) -- 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: Harden all packages with position-independent code
- Original Message - > Does this proposal apply to native non-C/C++ programs? As written, it seems to intend so. In practice, it would probably apply or not depending on whether the non-C/C++ programs’ builds are affected by _hardened_build. Ideally, I think this should apply to all languages that don’t ensure memory safety, and not to those that do ensure it.¹ (There is also the edge case of safe languages with explicit “unsafe” blocks, I guess these should default into the “safe” category?) Mirek ¹ This should not be much of an issue for processes that mix components written in multiple languages because the dynamically loaded libraries / modules have to already by position-independent; we are only discussing the main executable. -- 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: Change xorg input stack to use libinput
> Scrap that, Kevin Kofler pointed me to this post: > > https://lists.fedoraproject.org/pipermail/devel/2014-December/205490.html > > Which I unfortunately missed, so the info I got from KDE upstream is > not correct because the KDE spin adds an extra component which does > directly talk to the low level Xorg drivers, and there are plans to > integrate this into kdebase upstream. > > As a result of this Peter Hutterer and I have been rethinking the > plans for switching to xorg-x11-drv-libinput for F-22. So now we plan > to introduce xorg-x11-drv-libinput more carefully / slowly. > > The new plan is to only do this for the Desktop product, and thus for > the GNOME desktop. > > We've always planned to keep the old drivers around and allow people > to use those instead as a fallback plan, and the GNOME input configuration > changes which are in the works will also keep supporting the old drivers. > > I've updated the feature page to reflect this: > https://fedoraproject.org/wiki/Changes/LibinputForXorg > > I guess given the changes FESCo may want to re-visit this feature. If I understand correctly, this would amount to the inability to install both GNOME and KDE side-by-side, with both desktops’ touchpad configuration dialog working without manual involvement (because the driver change is done by installing/uninstalling packages or perhaps xorg.conf changes). That’s not the end of the world but also not ideal. Is there anyone interested in porting the kcm module in time for F22? Mirek -- 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: Set sshd(8) PermitRootLogin=no
- Original Message - > > = Proposed System Wide Change: Set sshd(8) PermitRootLogin=no = > > https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no > In the Server case, nearly every deployment is headless. Disabling root > login to ssh by default would mean that many people would have no way to > get into the system at all. (Yes, we could force the creation of a > non-root user at install time, but this user would by necessity be an > administrator capable of becoming root via sudo, so the distinction > is... fuzzy). No, there is an important conceptual distinction between logging in as a “hard-coded technical account named root“ and logging in as a real person (or a bacula/ansible service account, even if ultimately root-privileged through some mechanism), as soon as more than one person has administrative access: attribution and accountability. OTOH, the security distinction between brute-forcing (constant “root”+password) or (username+password) is trivial enough that I don’t think the change as proposed makes sense. > The only other approach I could see for the headless > servers would be mandating the enrollment in an identity domain at > installation time (such as to FreeIPA or Active Directory). > > Neither of those approaches is anything like ideal, I think we should eventually end up forcing _all_ logins (both remote and local) to actually identify a security principal (i.e. have a local user set up or a domain membership as a required step during installation). You are right that at this moment this would not go smoothly; we should make it smooth enough first, and then just remove the root password altogether to force going through a real account first. (https://lists.fedoraproject.org/pipermail/security/2014-December/002039.html ) > We can also consider opening an RFE against realmd, so that if the > machine becomes enrolled in a domain, it disables the remote root login > by default. I'm not sure about that, however. That seems like a fairly confusing combination of a mechanism (realmd as a tool “for joining domains”) and distribution policy (Fedora prevents/recommends not to use logins directly as root). Mirek -- 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: Set sshd(8) PermitRootLogin=no
> > > The only other approach I could see for the headless > > > servers would be mandating the enrollment in an identity domain at > > > installation time (such as to FreeIPA or Active Directory). > > > > And in this scenario we should absolutely disable PermitRootLogin. > > So that if you have issues with the connector, you have to reboot the > machine and be physically present to fix anything. > > Not really a grand plan IMO. Earlier in the discussions I was told that this is not really an issue: in production, about every server with remote access also has a KVM. Mirek -- 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: Harden all packages with position-independent code
Hello, > = Proposed System Wide Change: Harden all packages with position-independent > code = > > Harden all packages with position-independent code to limit the damage from > certain security vulnerabilities. So this proposal is for _all_ architectures, including the register-starved 32-bit i?86 where the overhead is, IIRC, around 10%. I am by now quite convinced that x86_64 should be using PIE by default. As for 32-bit, I’m torn between “this is too much overhead” and “32-bit isn’t worth the worry, let’s instead make the defaults consistent.” Mirek -- 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-01-07)
> Dne 7.1.2015 v 21:14 Stephen Gallagher napsal(a): > > * #1379 F22 System Wide Change: Change xorg input stack to use libinput > > - https://fedoraproject.org/wiki/Changes/LibinputForXorg (sgallagh, > > 19:51:28) > > * AGREED: Approved with two caveats: 1) Both GNOME and KDE must be > > updated by the contingency date or it goes into effect and 2) the > > contingency plan should note that it will may require reverting > > changes to the control panels as well. (+7, 0, -0) (sgallagh, > > 19:57:46) > > Thanks! > > WRT to the 2 caveats: > > 1) As mentioned in the feature page KDE does not need any changes since > its mouse settings panel does not talk directly to low level Xorg drivers. Quoting Kevin Kofler: > We ship kcm_touchpad on the KDE spin, which definitely does depend > on synaptics interfaces (search for "synaptics" in: > https://projects.kde.org/projects/playground/utils/kcm-touchpad/repository/revisions/master/entry/src/backends/x11/xlibbackend.cpp > ). > Anything that does not use the synaptics driver is not considered a > touchpad. And kcm_touchpad is also in the process of becoming a core part of > upstream Plasma. (It is currently in the git.kde.org playground.) > > Therefore, porting kcm_touchpad (the rewritten 1.x series we currently ship, > not the old, obsolete, 0.3.x version, please make sure you look at the > correct version) is an essential requirement before we can move away from > the synaptics driver. I don’t claim to know enough whether this is an “essential requirement” but it does seem like something to discuss and agree on with the KDE maintainers. Mirek -- 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: System-wide crypto policy transition tracker
> On Tue, Jan 6, 2015 at 10:20 AM, Nikos Mavrogiannopoulos < n...@redhat.com > > wrote: > > I've created a transition tracker to system-wide crypto policy at: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1179209 > > Also, what about situations where SSL/TLS is off by default in the > application, but is an available as an optional feature, if the user > configures it? Since users are obliged to configure it, it seems there's not > much for a packager to do in those situations, because that depends on the > user's configuration, right? No, even in such cases the user benefits from not having to understand, and more importantly, follow over time , the best practices for TLS. Ideally the user should just enable TLS and configure their private key, and should never need to touch the crypto configuration, and likewise for the vast majority of packages it is beneficial if the package maintainer can likewise depend on crypto-policy being maintained by competent experts. Mirek -- 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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
(on CLI) > > and developers deserve a better environment. > > No, developers deserve the environment they ask for, not what someone > else thinks is "better". There are aspects of the shell that are a matter of pure preference, like syntax coloring. There are aspects where personal preference or efficiency in the common case may override someone else’s idea of good design, like perhaps the textual programming language that can’t easily enough handle file names with newlines (which aren’t forbidden). But I feel quite confident in saying that having a debugger with breakpoints and the ability to view variables, instead of (bash -x) and sprinkling around echo statements, is a nowadays a basic expectation and an essential tool for productivity, not a frivolous personal preference. (And if the response is “use a non-shell language and a powerful editor if you that kind of functionality”, then that just proves my point.) Mirek -- 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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
> While I think you are right in some cases like cashier, isn't this > discussion really about the Fedora Workstation?! Since for this the > target user is a developer, can we just agree that in this case the user > needs both CLI and GUI apps (although some developers certainly sticks > to one of them). The gist is that * Nobody _should_ need to use a terminal: non-developers¹ don’t need it, and developers deserve a better environment. It’s “only” a matter of writing lots of new software. AFAICT Workstation would in some ideal future want to get to this state. (And non-Linux operating systems are getting closer and closer to this ideal over time.) * _Currently_ most Linux developers do need to use a terminal. So there is no right answer, only a trade-off: Make terminal usage discouraged and difficult for current users, and hopefully get better non-terminal environment in the future, or make terminal usage easy and the generally recommended way, and give up hope on the developer UI significantly improving for the future users. Mirek ¹ Again considering shell scripts and pipelines as “development”. -- 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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Hello, > Am 02.01.2015 um 21:05 schrieb Miloslav Trmač: > > Here, GUIs _as a category_ (not necessarily the GUIs we are currently > > providing) should always be better than CLIs _as a category_ simply > > because the GUI can in the worst case just copy the CLI layout and > > behavior so it will not be worse than a CLI; and then there are all the > > graphics and mouse interactions and shadows and animation that a GUI can > > do but a CLI can’t. > > no it can't > > a gui for "grep file | grep -v x | grep -y | sort | uniq | awk... > > newfile" is impossible because you *never* can build a GUI that is the > same way flexiable and still useable 1) This is “application development” in my earlier mail, the other category to which the generic claim above was not intended to apply. 2) Even then, except for the un-specified awk and invalid (grep -y), I have just reproduced the functionality in LibreOffice Calc, in about the same time it took me to look up (grep -y) and make sure that this must have been a typo. (Cue arguments that LibreOffice is not usable ☺ ) > > So I can see a case for being vocal about “nobody > > should need to use a terminal” even now; but that case critically depends > > on the ability of the community to actually write the better non-terminal > > interfaces. > > but you can't and won't use the GUI the same way on remote machines over > slow lines Those slow lines are disappearing, and will be pretty rare by the time we get any UI design finished and polished. Using web interfaces, or even a remote desktop connection, from computers or even tablets is nowadays very common outside of the Linux world; “we need to use ssh and vim because Internet is slow” is, AFAICT, simply no longer true. Mirek -- 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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
- Original Message - > well, and that is why there are tasks you *can * do 1000 times more > better in a terminal or in a 3-liner shell script with one or two params > and others where you are much faster using the GUI > > this world is grey > > hence everybody start using Linux should *know* there are terminal apps > and which ones and make his own decision if they fit the usecase and in > doubt be able to use both worlds The way I view it, there are two fairly separate cases: A) Application development (with a wide definition of an “application” as “teaching the system to do something new”, i.e. all the way from simple aliases and pipelines through 10-line shell scripts all the way to 10k-line shell or Perl script monsters). Yes, these things can’t be done in our GUIs nearly as easily, but there _really are_ large groups of people who never will, don’t want to, or are perhaps even forbidden from, doing such things (consider cashiers or bank tellers). So it is quite reasonable to hide these capabilities until the user indicates some kind of interest in developing applications (where “indicates interest” today probably means a Google search, so we can get away with requiring one or two non-obvious but easy to do steps to get developer access). Also note that the shell prompt is one of the worst application development environments still in wide use. Very weak and inconsistent programming language, no module system, minimal auto-completion/intelligence, no inline help, horrible debugging tools even compared to 1980s Turbo Pascal. It _should_ be possible to have a programming environment that is vastly easier to use than the shell prompt we have; but I have very little hope of this improving in the medium term. B) Application usage, interacting with applications somebody else wrote. Here, GUIs _as a category_ (not necessarily the GUIs we are currently providing) should always be better than CLIs _as a category_ simply because the GUI can in the worst case just copy the CLI layout and behavior so it will not be worse than a CLI; and then there are all the graphics and mouse interactions and shadows and animation that a GUI can do but a CLI can’t. So to get the best sofware system possible we should 1) actually write such better GUIs, and 2) tell people that such better GUIs are available. > what makes me angry is "nobody should need to use a terminal" “Nobody should need to use a terminal” is a case of 2) above [and partially a case of “shell is a horrible application development environment” from A)]. Note that "nobody should need to“ and “currently nobody needs to” are very different. And there is a major difficulty: doing 2) before 1) is done can be counter-productive, counter-productivity or in the worst case just dishonest; but doing 1) without 2) is likely impossible if the CLI capabilities keep expanding faster than we can add GUI interfaces to the same capabilities. So I can see a case for being vocal about “nobody should need to use a terminal” even now; but that case critically depends on the ability of the community to actually write the better non-terminal interfaces. Mirek -- 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: timedatex replacing systemd-timedated for NTP packages
- Original Message - > If we want to have this working correctly with chronyd/ntpd, at this point > it seems the only reasonable option is to replace systemd-timedated. > timedatex is a new implementation of the timedate interface that was > recently added to Fedora. It reads the list of NTP units from a directory > as systemd-timedated used to do. When installed, systemd will start it for > the timedate bus name instead of systemd-timedated. The timedate clients > should work as expected, please report bugs if not. > > One suggestion was to install it as a dependency of the NTP packages. > Is this a good idea? Should this first go through the Fedora change > process or at least be documented somewhere? I think having a package that “takes over” a D-Bus service name, and installing it by default but not in all possible installations, is surprising enough that it would benefit from a FESCo sanity check, yes. (I don’t at this moment have any specific objections to this but this does seem a little dangerous. The flip side is that it is probably impossible for FESCo to discuss the technical risk of timedatex without also discussing the underlying conflict about time synchronization clients.) (*Sigh* It would be so much better if people could come to a consensus on a single design and implementation instead of “show me the code“-like writing software that bypasses some other software… I suppose at least it is good that several people care about time synchronization. Oh, and I also want world peace, and ponies. Don’t forget ponies.) Mirek -- 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: Requiring all files in /usr to be world-readable?
Hello, - Original Message - > On Mon, 03.11.14 09:13, Miloslav Trmač (m...@redhat.com) wrote: > > Hello, > > - Original Message - > > > On Fri, 31.10.14 10:04, Andrew Lutomirski (l...@mit.edu) wrote: > > > > > > > I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467 > > > > > > > > Thoughts? > > > > > > I very much agree with this, but I'd really prefer if we'd list what > > > is allowed rather than just declare what is forbidden. > > > > What is the use case for such a blanket requirement? fpc/467 lists > > the virt thing I so far disagree with, and other uses cases in there > > actually need much less than all of /usr. > > We are working on allowing stateless system boot up with /usr. For > that I really want the ability that any user can copy /usr to some > other place without having privileges, and then boot that > up. Replicating a system shouldn't require privileges. Could you expand on the flow of thought from “stateless system“ to “distribution by replication” and (separately?) “administration/replication by any user”? I don’t see how that follows. > Moreover, the stateless systems stuff actually enables sharing /usr > over the network. In some setups network sharing servers tend to > refuse access to networked clients if the files are marked > inaccessible, under the assumption that root on the networked client > might not be the same as root on the server. Is this limited to treating root specifically, or generally anything non-world-readable? I am only aware of the former (in NFS). > In general, cleaning this up is basic hygiene, it makes things much > simpler, if you just allow 5 kinds of files, and that's it. It would make things more uniform, not simpler. Addition of the rule/assumption makes the design more complex. > > > A short list like this should be everything we should allow in /usr: > > > > > > a) symlinks > > > b) directories with access mode 0555 > > > c) files with access mode 0444 (optionally 0644 if owned by root user) > > > d) files with access mode 0555 (optionally 0755 if owned by root user) > > > e) files with access mode 2555 (optionally 2755 if owned by root user) > > > f) files with access mode 4555 > > Secondarily: The rationale that the executables of suid files are > > public and thus it is useless to make them non-readable is false for > > 1) any non-distribution packages 2) local rebuilds > > Fedora has no control about those and should not make any restrictions > on the stuff we don't control, don't package. But then we go back to “we don’t control it, so we can’t make that assumption on /usr contents, so we can’t design applications to require such /usr contents”; what Fedora packages is not all that relevant for designs that assume an _universal_ property over /usr. Or perhaps we should require it for a specific subset of /usr where we know that the benefits/uses enabled by such a requirement outweight the costs. > > 3) in-distribution packages for which the worm doesn’t carry > > pre-generated exploit parameters. > > This would be security by obscurity, nothing more. > > Also, it's wrong. Either you have a "worm" that carries a fixed set of > pre-generated exploit parameters. It will exploit what it can exploit, > and won't what it doesn't have any pre-generates exploit parameters > around. There is one more set: where the exploit parameters can be derived by automated analysis of the on-system binary (perhaps just using nm). Mirek -- 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: Requiring all files in /usr to be world-readable?
- Original Message - > I can't speak for virtme, but supermin won't read new files that are > added by the administrator. It only looks at files that it knows > (from RPM metadata) are part of RPM-installed packages, and only a > fixed list of Fedora-packaged RPMs are consulted, not random third > party RPMs[*] > > [*] Well, except if they replace a core Fedora RPM with a third party > RPM of the same name, but is anyone that crazy? Apparently such craziness does happen in various enterprise setups. I have no idea whether users that crazy intersect with users who would benefit from supermin or virtme; perhaps they do such crazy things exactly because they have their own, different, OS distribution system. > I don't > regard a project that has been successfully used in production for > half a decade to be a "hack", but you're entitled to your opinion. I am admittedly a pedant and “relying on assumptions that the system does not promise to provide” weighs much more to me than “it didn’t broke for the known users” :) Mirek -- 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: Requiring all files in /usr to be world-readable?
Hello, - Original Message - > On Fri, 31.10.14 10:04, Andrew Lutomirski (l...@mit.edu) wrote: > > > I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467 > > > > Thoughts? > > I very much agree with this, but I'd really prefer if we'd list what > is allowed rather than just declare what is forbidden. What is the use case for such a blanket requirement? fpc/467 lists the virt thing I so far disagree with, and other uses cases in there actually need much less than all of /usr. > A short list like this should be everything we should allow in /usr: > > a) symlinks > b) directories with access mode 0555 > c) files with access mode 0444 (optionally 0644 if owned by root user) > d) files with access mode 0555 (optionally 0755 if owned by root user) > e) files with access mode 2555 (optionally 2755 if owned by root user) > f) files with access mode 4555 Primarily: oh no, please don’t perpetuate the security-by-nonworking-rube-goldberg-machine that is denying write permissions to the file’s owner. If SELinux constraints apply this doesn’t do anything more, and if they don’t the owner doesn’t need any privileges or capabilities to change the permissions and regain the denied access. Secondarily: The rationale that the executables of suid files are public and thus it is useless to make them non-readable is false for 1) any non-distribution packages 2) local rebuilds 3) in-distribution packages for which the worm doesn’t carry pre-generated exploit parameters. There are very real benefits to making setuid files non-readable, especially in the 1) case, and if we prohibited making the s[ug]id files unreadable, the application authors would have to choose between violating the packaging standard and decreasing security. (Yes this is security-by-obscurity in the Kerckhoffs’-principle sense, but it is very effective against attackers that are not specifically targeting you or have limited resources, i.e. anybody less than a nation state.) > That said, there appears to be some form of cargo-cult programming > around, for example the audit packages carries a lot of non-sensical > access modes, for security theatre reasons. Some of the do seem nonsensical; making the audit.service non-readable is IMHO paranoid but not a security theatre. It is likely enough admins will edit that file instead of adding service.d files in practice even though the design says then shouldn’t, and then the configuration better be unreadable. (This is the flip side of moving configuration away from /etc/sysconfig and mixing it with non-intended-to-be-modifiable settings.) Mirek -- 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: Requiring all files in /usr to be world-readable?
- Original Message - > On Fri, Oct 31, 2014 at 01:59:30PM -0400, Miloslav Trmač wrote: > > - Original Message - > > > I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467 > > > > > > Thoughts? > > > My intuition is that if an application needs _everything_ in /usr to > > be readable then it is likely broken. Something being placed in > > /usr does _not_ imply that it is supposed to be used by everyone. > > That may be your intuition, but it's not a reason. OK, then let me write it more precisely: that application is relying on a property that was never documented or promised to be true. > There are programs > which have long needed to read all - or many - files from /usr > (supermin being one, since around 2009). Yes, I was specifically thinking of supermin as an example. > > An administrator can come and change the permissions at any time, > > Or they could delete RPM-managed files at random. Unlike deleting RPM-manged files at random, the administrator is can reasonably expect that creating more files and giving them whatever permissions they feel appropriate, both in /usr/local and in anything else they decide to place into /usr and package, will work and not break the OS. > > And if we look only at the cases that > > would be helped by the proposed guideline, i.e. only depending on > > Fedora RPM-distributed files (but not being particular about what > > the purpose of kind of file this is), the application would probably > > be better off just opening and reading the RPMs from repos directly > > instead of reusing whatever local damage could have been done to the > > partition. > > This is really slow, and requires network access. supermin can build > an appliance from /usr in a few seconds, without needing network > access. That’s a cool hack when it works, but it is not promised to work so the burden on handling the case when it doesn’t is (at least as /usr is currently defined) on supermin, and I’m not convinced that speeding up supermin is worth limiting the use cases of /usr. The primary purpose of /usr is storing components of running applications and the operating system, not a self-replicating distribution mechanism. And as for “everything is available in RPMs anyway”, 1) not all RPMs are publicly available, and 2) the argument about it being slow and requiring network access equally applies here. There _is_ a security benefit to an unprivileged attacker not knowing what the system’s policy is, and note that this doesn’t require modifiable state: it also includes drop-in files modifying the default policy, and packaged within (often site-specific) RPMs. The current (unstandardized BTW) push to move default configuration away from /etc into /usr naturally means that this drop-in default configuration should both be packaged as inaccessible to unprivileged users, and located in /usr. Mirek -- 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: Requiring all files in /usr to be world-readable?
- Original Message - > I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467 > > Thoughts? My intuition is that if an application needs _everything_ in /usr to be readable then it is likely broken. Something being placed in /usr does _not_ imply that it is supposed to be used by everyone. An administrator can come and change the permissions at any time, and the packaging guideline would not affect anything not included in Fedora-distributed RPMs. And if we look only at the cases that would be helped by the proposed guideline, i.e. only depending on Fedora RPM-distributed files (but not being particular about what the purpose of kind of file this is), the application would probably be better off just opening and reading the RPMs from repos directly instead of reusing whatever local damage could have been done to the partition. Perhaps there are useful subsets of files in /usr where mandating this would be useful; but all of /usr is seems like an unnecessary overreach. (And to the specific examples brought up: No opinion on systemd services; making setuid binaries not world-readable has a _definite_ benefit when prelink is set up, OTOH that is no longer a default.) Mirek -- 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: Cron jobs output are sent to the network by default
- Original Message - > I created a new bug [1] that explains that ssmtp is sending all cron > jobs output to an external SMTP server. I marked it as a security bug, > the security tag was removed and it was recommend to make it public, > something I can't do. I will resume the problem here, because there are > comments that says that it isn't a security bug, I disagree: > > 1- Fedora 20 shipped with the feature of not running a SMTP server by > default, I was fine with it because I don't need to send emails or > receive emails locally using it. > > 2- an update pulled ssmtp > > Apr 20 19:06:14 Installed: ssmtp-2.64-11.fc20.x86_64 > Apr 20 19:06:15 Updated: 1:smartmontools-6.2-5.fc20.x86_64 > > 3- ssmtp is configured by default to send emails to a host named mail > > 4- If a cron jobs runs the email is sent to mail.[your.domain] without > you ever configuring that. This is certainly not a reasonable default configuration for Fedora. While I think that it is not a reasonable default configuration for ssmtp at all, I could be persuaded otherwise; but in that case, it should never be installed by _anything_ that isn’t an explicit user’s choice (i.e. no dependencies direct or indirect, no comps group presence, and ideally/overzealously? an automated test that makes installing ssmtp in a default product configuration a release blocker). Mirek -- 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: rpm 4.12 and weak dependencies
- Original Message - > On Thu, Oct 9, 2014, at 11:09 AM, Miloslav Trmač wrote: > > > especially as we are taking the RPM-level control away from the users > > completely in cloud > > How is that? We ship filesystem images with many installed packages. Removing the packages from an existing image is possible but fairly pointless because it will not decrease the maximum image size. And the way to spin up a new VM quickly is to clone a disk image, not to install it from a set of RPMs. RPMs still exist but are not something users interact with the way we keep updating one RPM at a time in workstations. > > and Atomic images already. > > See: > > https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2014-October/msg5.html Interesting. Mirek -- 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: rpm 4.12 and weak dependencies
- Original Message - > The Fedora question would be not “what do the tags do” but “when is it > appropriate to use Suggests, when Recommends, and when Requires”? (And FWIW my take is that having this level of complexity in the dependency system is a mistake that is making things complex for the users and without giving them anything all that valuable in exchange, especially as we are taking the RPM-level control away from the users completely in cloud and Atomic images already. And in the reverse dependencies really scare me. But I realize this is a minority opinion, so it shouldn’t prevent answering the question with something else than “never”.) Mirek -- 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: rpm 4.12 and weak dependencies
- Original Message - > Most importantly, we need to update packaging guidelines to explain > what are the semantic differences between these different tags. But > that's a minor update. That seems to be well enough covered upstream. (Well modulo “does Fedora actually do what the upstream page says?“) The Fedora question would be not “what do the tags do” but “when is it appropriate to use Suggests, when Recommends, and when Requires”? Mirek -- 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: rpm 4.12 and weak dependencies
(reordering the citations!) > > > Why should we ban weak dependencies if they really > > > do nothing in YUM? > > > > We need a precise and detailed functional description about what these > > "weak dependencies" are supposed to do. > > Do you mean something like this? > > http://rpm.org/wiki/PackagerDocs/Dependencies That documentation belongs upstream (and should _not_ be just repeated within our packaging guidelines IMHO). Rather, there are Fedora-specific questions to figure out. * That page says that Suggests/Enhances: will prompt the user. Do any of the Fedora tools actually do that? Do the _relevant_ tools do that? If not, we shouldn’t be using these tags I guess. (This question impacts the packaging guidelines.) * Assuming our packaging tools do support the tags, what should the installable repo creation / live image creation do? What does it do? (This one doesn’t.) > > >> Before dnf gets promoted as the default package manager, it would be > > >> interesting to do some widespread testing. > > >> > > >> 1. document dnf behavior with weak dependencies and related > > >> configuration options > > >> 2. let people experiment and provide feedbacks > > >> 3. based on feedbacks either propose guidelines or status quo if > > >> that's ok > > > > > > I agree with Haïkel. > > > > I do not. > > I agree with Haikel and Petr, we have a great opportunity to test this and see > how it works. What exactly is the “it” you want to test and have a great opportunity to test? I assume the RPM and DNF upstreams do their own testing of this without depending on Fedora repos to carry such packages. Yes there are Fedora-specific questions but it seems to me that testing them is just not possible at this point. Mirek -- 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: Dash as default shell
- Original Message - > On 6 October 2014 17:28, Miloslav Trmač wrote: > > - Original Message - > >> > usage/requirement as well. Bringing the benefits of supporting dash to… > >> > the satisfaction of pedantically using the POSIX /bin/sh path as > >> > frequently as possible? > >> > >> Also known as portability, compatibility > > > > Upstreams can be interested in cross-distro portability and compatibility. > > I don’t see much benefit for Fedora and Fedora’s users. > > > > Fedora is never upstream? Ever? The cases where Fedora is both a distribution and upstream happen, but in these cases the difference doesn’t matter. It’s the other cases, where the roles are separate, that allow us to judge where the benefit, effort and policy should be allocated. > >> and transparency. > > > > Perhaps for changing the #! line; adding yet another programming language > > to the OS would make it more complex and thus _reduce_ transparency. > > Not another programming language, one that is already being used. If they have so different features and syntax that people writing scripts need to be aware of this, they are different languages. Or to put it the other way, if they were the same languages then assumption that /bin/sh is bash couldn’t matter. > >> Do we > >> encourage people to turn compiler warnings off? > > > > No, but most compiler warnings are useful _for increasing quality > > noticeable to users of Fedora_. A warning about use of a bash construct > > when we are using bash doesn’t help us help users. > > Getting dependencies right isn't helpful? That’s what I said, and I think I said why. If you think that changing dependencies, when it would change neither behavior nor on-disk contents is helpful, could you explain how? > Lastly: > http://en.wikipedia.org/wiki/Open_Build_Service > Even the scripts that you might think are solely Fedora specific could > be useful to other people. Good for the scripts. I suggest this should be handled it in the scripts’ upstreams and not Fedora’s packaging of them. Mirek -- 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: Dash as default shell
- Original Message - > > At that point switching anything to dash can _only increase_, not reduce, > > the disk space needed, and is very likely to increase the total page cache > > usage/requirement as well. Bringing the benefits of supporting dash to… > > the satisfaction of pedantically using the POSIX /bin/sh path as > > frequently as possible? > > Also known as portability, compatibility Upstreams can be interested in cross-distro portability and compatibility. I don’t see much benefit for Fedora and Fedora’s users. > and transparency. Perhaps for changing the #! line; adding yet another programming language to the OS would make it more complex and thus _reduce_ transparency. > Do we > encourage people to turn compiler warnings off? No, but most compiler warnings are useful _for increasing quality noticeable to users of Fedora_. A warning about use of a bash construct when we are using bash doesn’t help us help users. Mirek -- 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: Dash as default shell
- Original Message - > On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote: > > >Is it worth considering using Dash as the default (non-interactive) > > >shell in Fedora? Other distributions including Ubuntu and Debian > > >(https://lwn.net/Articles/343924/) have been using dash as the default > > >shell and Android uses mksh. While this appears to have been done > > >primary to increase bootup efficiency (which is not relevant with > > >systemd), it might help with security > > > > More bashism's in .spec files: > > + pushd src > > /tmp/rpm/rpm-tmp.047Jay: 43: /tmp/rpm/rpm-tmp.047Jay: pushd: not found > > All the other things aside, I think it'd be fine for us to leave bash as the > shell for spec file scripts even if we changed /bin/sh and/or the root > shell. At that point switching anything to dash can _only increase_, not reduce, the disk space needed, and is very likely to increase the total page cache usage/requirement as well. Bringing the benefits of supporting dash to… the satisfaction of pedantically using the POSIX /bin/sh path as frequently as possible? Mirek -- 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: Dash as default shell
> The expected security improvement is essentially nonexistent. In the current > case of importing functions from the environment (and we could have a looong > philosophical conversation about whether this is a vulnerability in bash or > in its callers, where the likely outcome is “not a vulnerability in bash but > by far easiest to fix in bash”) > Why would this be a philosophical discussion when there were clearly bugs in > the parser allowing things it shouldn't even if you consider the use cases > valid otherwise? As I said in the snipped part, anyone able to submit arbitrary input to a shell can already cause it to do arbitrary things. The parser bugs do not give the attacker anything they don’t already have, so they are not security-relevant. So we are back to the philosophical discussion about where is the vulnerability in putting untrusted data into the environment. Mirek -- 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: Dash as default shell
Hello, > On Thu, Oct 2, 2014 at 10:48 AM, Tom Rivers wrote: > > On 10/2/2014 09:58, Rahul Sundaram wrote: > > > > I didn't address it because it was not really relevant either. The > > > impetus > > > is > > > merely the backstory. > > > > > On the contrary, the rationale for your proposed change is very relevant. > > Sure but the rationale isn't just security as I have explained earlier. Do > read the links and other mails fully. OK, then; care to explicitly list the advantages you expect to see from such a switch, and why they outweigh the disadvantages and the migration costs? AFAICS: The expected security improvement is essentially nonexistent. In the current case of importing functions from the environment (and we could have a looong philosophical conversation about whether this is a vulnerability in bash or in its callers, where the likely outcome is “not a vulnerability in bash but by far easiest to fix in bash”), I expect/hope that the environment variable channel has been audited to death. Outside of this case, the shell is, by its nature, a programming language interpreter, and it doesn’t do any kind of privilege escalation: if you feed it arbitrary input, you get to do arbitrary things, but no more than you could do without the shell. The shell really should be transparent/fairly irrelevant to security (which is also why so little attention has been paid to it).¹ And as for any measure of performance, by the very fact that the scripts are written in shell we already know that the scripts are not performance-critical, or at least have not been worth optimizing for performance. So, it seems to me, all we are left with is a bit of performance/space optimization just because we can, at the very real cost of breaking existing scripts, both within the distribution and on users’s systems. Mirek ¹ The exceptions being attacks through other programs that do escalate privileges and call shell with untrusted data (as in shellshock), and attacks through the shared environment (in this case, mainly filesystem contents and various small/constrainted states like the PID space). -- 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: Crypto policies packaging guideline
- Original Message - > IMHO, we need a crypto-expert or team to formally review this proposal, Nikos, who proposed this, is a crypto expert :) > to identify packages it affects and to advise packagers and upstreams on > how to implement this, because I feel this proposal is way beyond the > scope of skill/knowledge of an average packager. The guidelines can and probably should be expanded to be more directly applicable to other languages, but IMHO making such a change in a package’s primary implementation language very much _needs_ to be within the scope of the skill expected of an average packager. Mirek -- 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: Crypto policies packaging guideline
Hello, (resurrecting an really old thread, sorry about the delay.) - Original Message - > 1) Will I (as a hobbyist packager) be able to reach the proper > conclusion, e.g. find the real place where these defaults are set, such > as [4, 5]? If you, as the package maintainer, who knows the package, can’t do this, who can? The security experts can grep for SSL_CTX_set_cipher_list as well as anybody, but following through the call chain and multiple langauges does require package-specific expertise. A distribution is supposed to be a set of software customized to work well together, and yes, that necessarily means understanding the source code and being able to change it. We _need_ to be able to do such things with Fedora’s packages; perhaps we haven’t been asking packagers for this much recently, but we need to start, and this is as good a reason to start as any. > 2) What about dynamic languages, such as Ruby, Python etc. They are not > covered by the guidelines at all. Yes, it would be good to expand the guideline to cover the bindings of the major languages. > 3) Should I really rewrite the upstream defaults and how? What will be > the impact on other libraries written in Ruby? Not mentioning that there > was quite lengthy controversial discussion upstream [6] and you ask me > again to override its results. By my uninformed estimation, the vast majority of TLS using projects either don’t have an explicit configuration (i.e. there is nothing to be done), or are not carefully maintaining the cipher list, unlike this recent Ruby change; and even projects that have recently updated it are not automatically guaranteed to keep maintaining it in the future. Libraries written in Ruby _should_ in general inherit the system-wide defaults, though, yes, this may in very rare cases result in additional patching of these libraries if they are connecting to specific services that are less secure and need custom configuration. (It might be interesting to compare the Ruby defaults list and the current version of the PROFILE=SYSTEM list.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
