Re: dnssec-trigger + GNOME + NetworkManager integration
On Wed, 2015-07-01 at 18:40 -0400, Paul Wouters wrote: > That's the same as saying remove the "continue anyway" frmo the > browser. Yeah, I want to do that too; actually I added it to Epiphany myself, not because it's a good idea, but because I know we'll be in for complaints otherwise, because Firefox and Chrome let you continue and we have to be just like them Basically all browser vendors agree that the Continue Anyway button was a huge mistake, but everyone is afraid to remove it for fear users will switch to a competing browser, so it's here to stay I'm afraid Anyway, if you think it's absolutely essential to have an opt-out, I guess we could have one buried in the network panel. But we don't want to advertise 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: dnssec-trigger + GNOME + NetworkManager integration
On Thu, 2015-07-02 at 00:44 +0200, Reindl Harald wrote: > the more important question: who do gnome developers think they are > to > make such decisions? Hi Reindl, If you know enough about TLS to decide whether to click the Load Anyway button in your browser on a particular site, or enough about DNSSEC to know whether you want to disable validation, then congratulations: you are the 1%. That's great, but we are building an operating system that needs to be safe to use for the 99%. An operating system that requires users to make confusing security-related decisions is not safe to use. Constructing such an operating system is not ethical. If you know what a session cookie is, that clicking the Load Anyway button in your browser leaks it to attackers, and why that matters, then you are the privileged minority, and our software is not designed for you alone. Our free software will respect users -- the entire user population, not just the 1% -- or it will be bullshit [1]. I don't expect you to agree with me on this, but there you have it. :) Michael [1] http://mjg59.dreamwidth.org/32686.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Wed, 2015-07-01 at 19:59 -0400, Paul Wouters wrote: > Principles are good and well. But how many times did you actually USE > that option you so reluctantly implemented? :) Actually, I honestly don't remember ever using it except testing it during development. I just don't visit broken sites. They are few and far between nowadays. Last time I found a broken site that I wanted to visit, I complained about it on my blog [1], and it got fixed. Actually, there was another time recently: I was planning to use the Bugzilla instance of a certain highly popular third-party distributor of software for Fedora, at the request of one of the developers, but it was broken (I think it used a worthless cacert), so I went on with my life instead. [1] https://blogs.gnome.org/mcatanzaro/2015/01/30/mozilla-is -responsible-for-the-redhat-corpmerchandise-com-fiasco/ -- 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: Pre-nonresponsive maintainer request
On Wed, 2015-07-01 at 21:33 -0500, Richard Shaw wrote: > I haven't gone through all the requirements but it seems pretty clear > that brasero is unmaintained. FWIW, it's unmaintained upstream as well. If anyone is looking for a GNOME package to take care of -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2015-07-01)
On Thu, 2015-07-02 at 09:55 +0200, Tomas Hozza wrote: > * AGREED: Netizen is not approved as spin. We approve the option to > have netizen as optional suite in anaconda. Please work with > Workstation WG. (+7, 0, -0) (thozza, 18:48:50) Hi, maybe there was some misunderstanding about the Workstation installer, but we don't allow configuration of package selection. Users are expected to use GNOME Software once the system is up and running. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Thu, 2015-07-02 at 16:38 +0200, Reindl Harald wrote: > this type of attitude? > > everybody who reads IT news over the past years about CA's issued > certificates even for Google knows that a CA signed certificate does > not > prove anything - the real problem is wehn this happens for Google > somebody takes notice and the press writes about it > > if the same happens for your domain nobody will recognize it The situation is going to be getting a lot better in the near future, though. We're getting to the point where we can start enforcing Google's certificate transparency: if your certificate isn't on the public audit list, we can simply reject it. That allows individual web sites to get an immediate heads-up whenever any fraudulent certificate is issued for their site. (And researchers will be looking after the most important sites, of course.) That's not going to fix TLS in itself, because most sites probably don't care, but if the site does care, it will be impossible to issue a browser-trusted certificate for the site without that site knowing. (At least, that's my understanding of the technology; I haven't researched it thoroughly.) You're right that OCSP is worthless. GNOME applications don't currently perform any certificate revocation; I'm not willing to implement OCSP unless Firefox is willing to enforce it, and they aren't. We should implement OneCRL, which solves the revocation problem for intermediate certificates, but there doesn't seem to be any reasonable solution for individual sites yet. OCSP must-staple seems promising. Of course, we can't have any of these nice features in GNOME unless somebody wants to pay for their implementation. (If so, get in touch please.) Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Fri, 2015-07-03 at 15:43 +0200, Petr Spacek wrote: > For the record, and all this can be solved by DNSSEC + DANE. See RFC > 6698. I was planning to use DANE as a second required check in addition to the normal certificate chain. That is, if either the certificate chain doesn't check out or DANE fails, then something is spooky and the site should be inaccessible. Other browsers are throwing around ideas about using DANE to make the site accessible in the event the certificate chain fails, which seems like the wrong direction to me. I haven't really seen any good arguments in favor of one approach or the other, though. Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Fri, 2015-07-03 at 11:21 -0400, Mike Pinkerton wrote: > Isn't the whole point to eliminate the need for third party > certificate authorities entirely? Well I think you could choose to do that, or you could choose to use it as an additional security measure on top of traditional certificate authorities. > Just to clarify what you are saying -- if there is a third party > certificate chain which fails, then you would distrust the site. But > > if there is no third party certificate authority chain, and DANE > succeeds, then you would accept the DANE-provided certificate and > trust the site. I was thinking to require both to work, instead of just one or the other. Seems like that would make life hardest for the attacker. Anyway, we'll probably wait for some major browser to use DANE first (probably won't be Chrome [1]) and then copy what they do for GNOME. Michael [1] https://www.imperialviolet.org/2015/01/17/notdane.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2015-07-01)
On Tue, 2015-07-07 at 11:18 +0200, Tomas Hozza wrote: > How is the Live installer different from the network installer? Is it > just some configuration thing, or are those completely different > installers? It looked like regular Anaconda last time I installed > Workstation. It's the regular installer with fewer options (e.g. there is no possibility for software selection, and almost all of the network configuration options are removed) and it runs way faster (since it's just copying an image to disk, not installing individual RPMs). > I'm just trying to understand if you don't want to give the user the > option to choose the installation options from live CD on purpose > (due > to user experience or such) or if there is some real issue? We want the installer to be as simple and easy-to-use as possible. Our philosophy is that anything that can happen after installation should happen after installation. The installer takes care of setting up the operating system, then you can go from there. (Furthermore we don't expect users to be familiar with the packages offered, and can't really do quality control on the different package sets.) There are also some big bonus points for this approach: * Much faster installation (it takes ~5 minutes for me, not on an SSD) * Much smaller download size (we can't provide any serious software selection in 1.5 GB) For Fedora 24, we've proposed trimming down Anaconda much more, since most of Anaconda's functionality is redundant with our initial setup tool that already handles language, keyboard, and timezone selection: h ttps://listman.redhat.com/archives/anaconda-devel-list/2015 -June/msg7.html We do have the alternative network installer for power users who want to configure software selection at install time. The network installer is the full-featured Anaconda, and I expect it always will be. But that's not the download we advertise to users; we relegate it to a sidebar on the download page. And I think the default set of packages will probably be a bit different (you might get some packages that we've blacklisted from our live installer; this used to be a problem, not sure if it still is). -- 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: Orphaned Packages in rawhide (2015-07-07)
On Tue, 2015-07-07 at 13:04 +0100, Richard W.M. Jones wrote: > Looks as if there's a lot of fall out from this. > > rpm -qi says "GNOME library for CUPS integration", which sounds > important. > > Does anyone know if this library has been replaced by something else, > or if it just needs someone to step up and own the package in Fedora? It's not important; it was last released in 2008, so it's obsolete for a very long time. Looking through the list of affected packages, I don't see anything that I'm concerned about losing for Fedora Workstation (all the GNOME packages listed there are also obsolete). Except the OCaml stack clearly has a problem. Feel free to pick it up if that's easier than figuring out what's wrong. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2015-07-01)
On Tue, 2015-07-07 at 08:54 -0500, Chris Adams wrote: > Once upon a time, Michael Catanzaro said: > > For Fedora 24, we've proposed trimming down Anaconda much more, > > since > > most of Anaconda's functionality is redundant with our initial > > setup > > tool that already handles language, keyboard, and timezone > > selection: h > > ttps://listman.redhat.com/archives/anaconda-devel-list/2015 > > -June/msg7.html > > Unless the installer is not going to ask any questions or give any > information, language and keyboard are needed for input/output during > install. We actually need to ask for language/keyboard layout before ever starting the installer. Currently the live environment is English language and US keyboard layout, and good luck figuring out how to change that (you need to open System Settings and navigate through the English UI) unless you're already familiar with Fedora. So Anaconda is actually too late to configure these. > Installing the system without configuring the clock can lead to > booting > into a system with files that were written in the future, not being > able > to join network authentication systems, and confusing/invalid install > logs. I think our plans for time are hazier. We can normally use NTP to try to fix the clock if it's in the future, but if NTP is unavailable (it's blocked, or there's no network access...) then maybe we should show the timezone panel in the installer after all. (For that to work well, Anaconda would need to learn how to tell gnome-initial-setup not to run timezone selection.) You can always change the clock and timezone with System Settings regardless, so it's just the same discoverability issue that we want to fix with language and keyboard layout, except in this case we'd rather not prompt until after the installation if we can avoid it. Michael -- 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
On Thu, 2015-07-09 at 11:22 -0400, Stephen Gallagher wrote: > Is there any case to allow Supplements: in the Fedora Collection? It > seems to me like this could be problematic. (e.g. I write a plugin > for > a popular engine and package it, then add Supplements: so that it > gets > pulled in by default whenever that engine is installed. My plugin > then > causes things to crash.) I think it is reasonable for us to forbid > Supplements: except with FPC exemption. It should be up to the owner > of > the primary package to decide to add Recommends: instead. The new guidelines say "reverse dependencies may be used with the agreement of the package maintainer of the targeted package" which seems good enough to me. "Reverse dependencies are mainly designed for 3rd party vendors who can attach their plug-ins/add-ons/extensions to distribution or other 3rd party packages. Within Fedora the control over which packages a package requires should stay with the package maintainer. There are, however, cases when it is easier for the requiring package not needing to care about all add-ons. In this cases reverse dependencies may be used with the agreement of the package maintainer of the targeted package." -- 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
On Thu, 2015-07-09 at 21:42 -0600, Jerry James wrote: > If that is not what the word means, then a definition > in the introduction would be very helpful, since there is no > definition anywhere on that page. A hint is a weak dependency that does not affect the default package suggestion: Suggests and Enhances. Recommends and Supplements are not hints. There is a little table at the top of the wiki page; maybe it could be more clear. -- 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 Weak Dependencies and the install media compose process
On Fri, 2015-07-10 at 08:20 -0400, Josh Boyer wrote: > You didn't offer your opinion on which of the three options you think > we should go with. I would offer option 1 is the one we'd pick. It > honors the intentions of the package maintainer the best. Which > would > you choose? Option 2 is just weird. If a packager uses Suggests to express a dependency, that means the dependency should not be installed automatically. If packagers have to think "is my package installed by default and if so would it be bad to have this Suggested package installed as well," that's going to make Suggests much less useful. Option 3 would increase the need to manually add missing packages that we actually want. For instance, we currently have evince-browser-plugin listed in comps for Workstation as a workaround for not being able to use Recommends in Evince's spec. If we go with Option 3, we'll need to keep it there forever. If a package shouldn't be installed by default with another package, then Recommends should not have been used! I think Option 1 is the best, so that package maintainers don't have to think separately about the difference between install media compose and normal package installation.. -- 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: Is it time to allow Chromium in Fedora?
On Tue, 2015-08-11 at 14:54 -0400, Neal Gompa wrote: > I think if we're willing to grant such an exception to Firefox, we > should be willing to extend the same to Chromium. That is, of course, > provided that we can actively work towards cutting away at bundled > libraries and getting the engine switched from FFmpeg to GStreamer. > Right now, the effort to switch from ffmpeg to GStreamer is being > done largely by Samsung, and I think that variant of Chromium is much > more appealing due to the pluggable codec framework in GStreamer. I'd > rather not have Fedora ship Chromium with a gimped ffmpeg if we > didn't have to, but it would be acceptable if using Samsung's efforts > to offer GStreamer support isn't appealing right now and that the > bundled ffmpeg libraries are split out into a subpackage. Unfortunately I would not count on Samsung's work to be upstreamed, as Google will never use it. The GStreamer folks are hoping for it to be upstreamed but acknowledge there is no chance it will be built by default. This is an optimistic hope; it is not unlikely that it will need to be maintained out-of-tree indefinitely. In this case, it would be better to use Samsung's Chrome as our upstream, rather than Google's. Still, I think the bundling exceptions are reasonable. In particular, there is no reason for Firefox to receive exceptions if Chromium does not. (The justification for Firefox is "active security team"; Chrome has that too.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bodhi 2 now live
FWIW I think the new version looks much nicer than the old one. Hopefully the issues will be ironed out. On Thu, 2015-08-20 at 17:48 +0200, Kevin Kofler wrote: > * The formatting of the update notes has changed in some ways (line > breaks > gone missing?), breaking my nicely formatted notes, e.g.: > https://bodhi.fedoraproject.org/updates/calamares-1.1.2-1.fc23 > (The enumerations were turned into one paragraph with bogus > italics.) This one's a feature I think: updates are already displayed to the user in markdown -- at least in GNOME Software, and I think even the obsolete GNOME Package Updater, and I think Muon as well? not sure about Apper -- so users are going to see your updates in italics no matter what. You'd be forgiven for not realizing this, since the web interface did not show this. That was a serious problem. (I'd like to hope/assume that the markdown parser is the same as is used in the user-facing system update tools) -- 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: when DEP-3 compliant patches in Fedora?
On Fri, 2015-08-28 at 14:40 +0200, Kevin Kofler wrote: > I am opposed to any such scheme, because it means we could no longer > produce > our patches with diff without hand-editing them. > > Such information, if needed, belongs into specfile comments. Let's do that then. openSUSE already has established required comments for patches in specfiles: https://en.opensuse.org/openSUSE:Packaging_Pa tches_guidelines#Patch_markup_.28also_called_.22Tagging_patches.22.29 It works well in practice. It's not hard to write, and it more helpful than the Fedora tradition of just adding a link to the upstream bug. Maintainers in openSUSE understand that it is required. -- 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: No autocomplete for new package in bodhi 2.0?
On Sun, 2015-09-13 at 19:28 +0100, Tom Hughes wrote: > Normally you're right, but if the package has only just been created > then it doesn't work. I assume bodhi catches up eventually but there > is > definitely a delay when a new package is created during which bodhi > won't find it and you have to enter the build name instead. I gave up trying to edit an update last week, because the new Bodhi wouldn't autocomplete the build name, and I couldn't enter it manually either. This was ridiculously hard to do in the old Bodhi, though, to the point where I would normally give up and use fedpkg, so it's not really a regression Michael -- 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: Disable PulseAudio flat volumes to prevent it from pushing volume level to max
On Thu, 2015-09-17 at 15:33 -0700, Thomas Daede wrote: > That said, flat-volume is the upstream default so we might want their > input, as well as looking at what other distros do. Ubuntu disables it. To the best of my knowledge, all other distros stick with the upstream default. I am in favor of disabling. It can be extremely frustrating when apps are misbehaving. Michael -- 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: Disable PulseAudio flat volumes to prevent it from pushing volume level to max
On Mon, 2015-09-21 at 18:00 -0400, Owen Taylor wrote: > There is danger to the ears if an application assumes that 100% > volume > is a safe volume and blindly sets its volume to 100% without user > input. But that only affects that application - one application's > misbehavior never affects another application. That's definitely not correct. With flat volumes, applications can and do set the system volume to 100%. I've received numerous complaints about this. It's particularly frustrating when watching YouTube videos, since YouTube sets the system volume to 1 when starting a video. We are still waiting for some promised "browsers API" in PulseAudio to fix this easily. I think it's telling that this thread is full of complaints about flat volumes, with no supporters. Also, Ubuntu does not seem to be getting any complaints about the lack of flat volumes. :) Michael -- 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: Disable PulseAudio flat volumes to prevent it from pushing volume level to max
On Mon, 2015-09-21 at 17:46 -0700, Thomas Daede wrote: > In the case of Youtube, you shouldn't be having any issues because > Mozilla switched to using a soft mixer internal to Firefox: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1046814 > > If you still have issues, you should report them upstream. > > (note that this means all website volume sliders are designed to > behave > as a mixer, not as flat volumes) Hi, sorry I forgot to say "in WebKit," which rather changes the meaning of my email. The relevant developer is still trying to avoid mixing streams internally. I do not understand it all very well, except the problem goes away when flat volumes are disabled. :) PulseAudio is going to offer some "browsers API" that will somehow allow fixing this properly, but that does nothing to help with all the applications that don't understand flat volumes, and in the meantime we are stuck with the bug Cheers, Michael -- 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: bugzilla search missing fields; can't find if F21 dracut bug filed lately
On Thu, 2015-10-01 at 04:53 -0400, Felix Miata wrote: > doesn't any kind of list in SeaMonkey (maybe because of noscript?) Yeah, the fact is that NoScript is incompatible with the Internet... probably that's not how the web should be, but it is how it is For those of us not blocking the scripts, the Bugzilla upgrade is a huge improvement. Those gigantic combo boxes were horrible to use; typeahead find is way nicer. I smile each time I use it; eventually I will get used to it, but for now, being able to easily move bugs between components for the first time is still a huge deal to me. Maybe you could whitelist RH Bugzilla? I think I trust Red Hat not to collect data on me for behavioral advertising, or mine Bitcoin on my computer, or use my computer to DoS Oracle Michael -- 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: Add Gparted into Live's
On Sat, 2014-08-09 at 02:33 +0430, Hedayat Vatankhah wrote: > GParted provides a number of essential features users might need, some > of which are not provided even by any command line tools in Fedora > repositories: resizing and moving partitions/filesystems. And > something like resizing FAT partitions is what I have not seen in any > other tools in Fedora repositories except kde-partitionmanager. > Anaconda provides resizing facility, but not move. Also, I'm not sure > if Anaconda can resize FAT partitions. Hi Hedayat, gparted should not be included because it's an advanced tool for technical users, whereas Fedora Workstation needs to contain only tools that are easy for everyone to use. Keep in mind that programs included in the live image will also wind up on the installed system. Michael signature.asc Description: This is a digitally signed message part -- 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: Add Gparted into Live's
On Fri, 2014-08-08 at 17:30 -0700, Thomas Gilliard wrote: > Unfortunately gparted is the only way to repair a usb stick dd'd with > fedora. Need to use gparted's "create a new mbr" and formatting it > fat32, boot flag set. The included "disks" does not seem to have this > feature. Disks can do this. I presume you know how to use Disks to format the stick and create a new FAT 32 partition, since that's pretty straightforward. To make the partition bootable, highlight the partition, select Edit Partition from the little gear menu at the bottom, then check Bootable. > This is needed for fedora liveusb-creator GUI to create a bootable > live USB stick. Or you could use Disks to create the bootable live USB stick without messing with any of this: just open the gear menu and click Restore Disk Image. You can also right click on the file in Nautilus and select Open With -> Disk Image Writer, which takes you to the same place (and the only thing you have to do is select the stick from the dropdown menu; couldn't be easier). signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Maximum length of command line arguments
This is of little practical consequence unless someone really wants to pass a 2 MB command line to a program... but as a curiosity, I ran a diff of a Koji build log from last year against a build from this year, and I noticed something odd in the configure spew. Old build log: checking the maximum length of command line arguments... 1966080 New build log: checking the maximum length of command line arguments... 1572864 Anyone know why this got smaller? It's 1572864 on my F20 machine as well. signature.asc Description: This is a digitally signed message part -- 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: appdata questions
On Wed, 2014-08-20 at 15:42 +0200, Karel Volný wrote: > why do we penalize users by hiding contents from them when some > upstream > just doesn't care about this stuff? (see also comment 7 about the > "unjust > burden")? To clarify, the goal is not to penalize users: quite the opposite. We want applications in the software installer to have good descriptions and screenshots to help the user decide if he wants to install the application. The status quo in F20 is that many apps have just a sentence fragment of description taken from the desktop file, which is not very helpful to users and makes our software center look bad. Hiding applications without good descriptions will improve the quality of the results we show, and also encourage Fedora packagers to add the descriptions. (If upstream doesn't want to add an appdata file, you can do so in your packaging!) Michael signature.asc Description: This is a digitally signed message part -- 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 3.13.91 megaupdate
On Mon, 2014-09-01 at 12:40 +0200, Kalev Lember wrote: > But if you have anything extra to add, other builds that aren't > in f21-gnome, feel free to add those to the spreadsheet and I'll pick > them up for the megaupdate. It's missing hitori and the adwaita-icon-theme packages. signature.asc Description: This is a digitally signed message part -- 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Mon, 2014-08-18 at 23:48 +0200, Kai Engert wrote: > Hello, > > this is a heads-up for an update to the ca-certificates package that > I've just submitted for updates-testing for Fedora 19 and 20. > > The upstream Mozilla CA list maintainers have decided to start removing > CA certificates that use a weak 1024-bit key. Although those > certificates are still valid, Mozilla has worked with the CAs, and they > did agree that it's OK to remove them. Hey Kai, This update has caused a lot of pain for Epiphany. Could you take a look at [1] when you get a chance and help us figure out what's gone wrong? Thanks! [1] https://bugzilla.redhat.com/show_bug.cgi?id=1134602#c3 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
auto-update-debuginfo and F21
Hi all, In Fedora 20, if you update your system with yum then the yum plugin auto-update-debuginfo will enable the debuginfo repository, update the debuginfo packages you have installed, then disable the debuginfo repository. If you update with GNOME Software or Apper, this doesn't happen and you wind up with debuginfo packages that don't match the packages you have installed. They update your debuginfo just fine if you enable the debuginfo repository manually by modifying /etc/yum.repos.d. I think it's really time to fix this. Is there any reason we don't simply have the debuginfo repository enabled by default? Alternatively, it could be enabled the first time debuginfo-install is run. Michael signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
On Sun, 2014-09-07 at 22:18 -0700, Adam Williamson wrote: > > - intercepts coredumps > > not on Fedora, abrt does that. It's on the roadmap. coredumpctl is really great, and it's wonderful that the ABRT devs are working on this. I don't care too much about the rest of systemd, but coredumpctl makes daily life a little bit easier. (If you don't have ABRT installed, then systemd beginning in F21 will indeed handle core dumps now, but you can always turn it off if you don't like it.) signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
On Sun, 2014-09-07 at 22:18 -0700, Adam Williamson wrote: > > - has tools for setting the system time and timezone, and locale > > Sure. They're useful. In GNOME, our settings panels previously only worked on Fedora and Debian, with some half-functional code for Arch and openSUSE, because each distro handled these differently and required custom code. Now we have no special casing for different distros, and it works everywhere these D-Bus interfaces are present (including systems without systemd that provide it, like Ubuntu). I don't really care where these interfaces live, but they need to exist somewhere, and systemd seems like the logical place for them. signature.asc Description: This is a digitally signed message part -- 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote: > Unfortunately only NSS works. Both openssl and gnutls fail to connect to > popular sites because of that change. It should not be assumed that the > users of ca-certificates are only programs using nss. [1] is an interesting read. I get the impression that certificates are being removed as long as there is a compatible replacement that NSS can validate, based on NSS's custom strategies for certificate validation. Is this claim accurate? This is a very big problem for the GNOME stack, which uses gnutls. We're getting complaints about sites that Epiphany can't display because the CSS fails certificate validation, or sites that don't display at all, which all work fine in Firefox. > I guess this is verification based on the rfc5280 path validation. > Unlike that NSS ignores the provided trust chain and tries to construct > a new one internally. That's interesting and happens to work around the > issue here but it is not and must not be required for all software to > reconstruct trust chains. The TLS is very specific on that issue, the > chain is provided by the server. From my perspective as an application developer who wants the Internet to "just work," and where proper functionality is defined as "whatever Firefox and Chrome do"... any deviation from NSS's behavior is problematic. :/ I know this is unfortunate but that's the reality of the Internet. We have a partially-finished port of glib-networking from gnutls to NSS, I guess for this reason. Intermediate cert caching is another big pain point. My university ran an important site for years without a chain of trust, and kept closing my issue reports until I realized that they were using Firefox to validate their chain of trust, and the cert that had signed the only one they were sending was cached for them. This behavior is harmful not just to other browsers, but also to Firefox users who happen to not have that certificate cached yet. > I do not agree. Such changes are dangerous to be performed on a stable > release, and may introduce more issues than solve. Ca-certificates > should not assume that NSS is its only user. That is either (1) it > should include the trusted certificates that are still in wild use, or > (2) it should include the intermediates of the trusted certificates that > are in use. I think (2) is what they're trying to do in [1], but it looks like this relies on NSS-specific behavior. (And I'm aware that [1] is just one case out of many.) [1] https://bugzilla.mozilla.org/show_bug.cgi?id=986014 signature.asc Description: This is a digitally signed message part -- 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Mon, 2014-09-08 at 17:07 +0200, Nikos Mavrogiannopoulos wrote: > I understand but this is not the case here. The internet isn't broken > because of gnutls and openssl have some limitation, but because the > current NSS derived ca-certificates work assume the NSS validation > strategy. This should not be allowed in the Fedora package. I would say, "The Internet is broken because NSS is more permissive than gnutls and openssl, and also because the current NSS derived ca-certificates assume the NSS validation strategy." Even once this fallout gets straightened out, we will still have cases of sites that work in Firefox and Chrome but not in Epiphany, which is unfortunate. Thanks a bunch for your help with debugging the issue! Michael signature.asc Description: This is a digitally signed message part -- 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Mon, 2014-09-08 at 23:26 -0700, Adam Williamson wrote: > certificate_list > This is a sequence (chain) of certificates. The sender's > certificate MUST come first in the list. Each following > certificate MUST directly certify the one preceding it. We recently learned the hard way in GNOME that if you rely on this behavior, some sites won't work because webmasters test their sites with NSS, and NSS doesn't care which order certificates are sent in. (gnutls can reorder certificates too, though.) signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
timedated is broken by default in F21
On Tue, 2014-09-09 at 10:38 +0200, Miroslav Lichvar wrote: > Yeah, that was nice, when it worked as we wanted. Unfortunately, with > the latest systemd the NTP service which is enabled/disabled by > timedated is no longer selected from the services installed on the > systemd, but is now hardcoded to the systemd SNTP client (timesyncd). > > That means the NTP status reported in GNOME settings may be incorrect, > enabling/disabling NTP will do nothing if another NTP service is > enabled > or timesyncd will be enabled even when our default NTP client > (chronyd) is installed. > > https://bugzilla.redhat.com/show_bug.cgi?id=1136905 > > Upstream is not interesting in having this configurable. Should we be > patching timedated? Or GNOME? Miroslav, This is clearly a problem. We don't want the NTP switch in gnome-control-center to stop working just because a distro decided to use an "alternative" NTP client like ntpd or chronyd. It looks like we have three options: (1) carry a downstream patch to systemd, (2) carry a downstream patch to gnome-control-center, or (3) drop chrony from the default install. (Is there any reason to keep chrony?) If all three sets of maintainers are resistant to such a change, then we should escalate to FESCO and let them choose for us. Michael signature.asc Description: This is a digitally signed message part -- 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: timedated is broken by default in F21
On Tue, 2014-09-09 at 08:37 -0500, Michael Catanzaro wrote: > (1) carry a downstream patch to > systemd, (2) carry a downstream patch to gnome-control-center Note that (1) would be much easier, since that patch is small and already exists. I expect other distros will either do this, or, more likely, leave gnome-control-center broken. I can see Fedora switching to timesyncd, but I doubt there's a realistic chance of that happening in Debianland or other major distros. > or (3) > drop chrony from the default install. (Is there any reason to keep > chrony?) Reading [1], it looks like there is a good reason to keep using chrony. [1] http://lists.freedesktop.org/archives/systemd-devel/2014-August/022537.html signature.asc Description: This is a digitally signed message part -- 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Wed, 2014-09-17 at 14:16 +0200, Kai Engert wrote: > I think it's good that we have started experimenting with these > removals > in the testing areas of Fedora, because it raises awareness of these > issues, and hopefully can bring higher priority to getting OpenSSL and > GnuTLS enhanced. > > But given the heavy complaints, maybe it's necessary that we delay > shipping the upstream removals into stable Fedora a little longer, > until > we have a better solution (either by having OpenSSL/GnuTLS enhanced, Sounds good. Thanks for taking this issue seriously! > or > maybe by implementing a way that enables users/admins to re-enable > legacy CA certificates). For the purposes of Fedora Workstation, no user intervention should be required. Michael signature.asc Description: This is a digitally signed message part -- 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: [Test-Announce] 2014-09-22 @ 15:00 UTC - Fedora QA Meeting
On Sun, 2014-09-21 at 19:55 -0700, Adam Williamson wrote: > * Anything else? The dual boot release criteria? Would be nice to get those finalized as soon as possible. signature.asc Description: This is a digitally signed message part -- 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: Proposal: Increasing application icon sizes to 64px
On Mon, 2014-09-29 at 22:05 +0100, Ian Malone wrote: > Who is using magnifying glasses to view icons? Icons are displayed far larger in GNOME Shell than in other desktop environments, and the difference between an SVG icon and a 256x256 icon (the mandatory minimum size for GNOME apps, and I'm definitely not the maintainer of several apps with only 128x128 icons, don't look at me) is fairly noticeable. 48x48 is really too low. 64x64 is too low signature.asc Description: This is a digitally signed message part -- 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: Proposal: Increasing application icon sizes to 64px
On Wed, 2014-10-01 at 08:57 +0100, Ian Malone wrote: > That might be a good reason, but it's not the one given at the start > of this proposal, that was that larger icons are needed for the > software centre (i.e. for applications to get included in the > installer) due to higher resolution displays. I think the software center and shell display icons at the same size, so it matters equally to both. signature.asc Description: This is a digitally signed message part -- 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: Proposal: Increasing application icon sizes to 64px
On Wed, 2014-10-01 at 08:19 -0500, Michael Catanzaro wrote: > I think the software center and shell display icons at the same size, > so > it matters equally to both. I would be smarter if I checked such facts BEFORE sending emails and not immediately AFTER. The icons in Software are indeed smaller. signature.asc Description: This is a digitally signed message part -- 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: How to handle upgrades to Fedora 21
On Fri, 2014-10-03 at 17:06 -0400, Owen Taylor wrote: > standard: choose this if none of the above apply; in particular > choose >this if you are using an alternate-desktop spin of Fedora I'd add a comma right after "in particular." > Feedback from this wide audience appreciated. Would you know what > option > to pick? Yes, it's clear. I agree with Rahul that "standard" is not a great name for the nonstandard, non-productized upgrade, though. "Generic" is more descriptive anyway. signature.asc Description: This is a digitally signed message part -- 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: How to handle upgrades to Fedora 21
On Fri, 2014-10-03 at 19:37 -0400, Ray Strode wrote: > I'm not sure it's worth repainting the bikeshed at this point, but > during the alluded-to discussion a few alternative names came up that > would have been better than fedora-release-standard: > > 1) fedora-release-nonstandard That this was the first item on the list suggests that fedora-release-standard is not the right name. :) In fact, most of the names on your list are antonyms of "standard." > 3) fedora-release-diy Not a good name for spins. This sounds like Gentoo. > 4) fedora-release-noncompliant This one makes it sound like not running a product is a bad thing. Let's avoid this one. All the other names are fine. I still like fedora-release-generic the best. My favorite color of paint is Myrtle Green. It's a nice color. [1] Michael [1] https://en.wikipedia.org/wiki/Shades_of_green#Myrtle_green signature.asc Description: This is a digitally signed message part -- 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: btrfs as default filesystem for F22?
On Fri, 2014-10-03 at 08:42 +0200, Juan Orti Alcaine wrote: > Anyway, I recommend using only the core features (snapshots, raid1, > scrubs, balances, cp --reflink, etc...), because others have many > quirks, like send/receive which get corrupted from time to time, raid > 5/6 which is work in progress, or problems related to low free space. FWIW: openSUSE has disabled very many btrfs features because they aren't stable enough. [1] FWIW: SUSE Linux Enterprise 12 will likely also be shipping with btrfs as default later this year, unless they've changed their plans. FWIW: openSUSE is actually using xfs for /home and btrfs only for everything else. Happy Sunday, Michael [1] http://lists.opensuse.org/opensuse-factory/2013-09/msg00029.html signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New hardware for Retrace Server
On Wed, 2014-10-15 at 18:02 +0200, Michal Toman wrote: > - Retracing now runs in memory, which means faster generating of > backtraces (by an order of magnitude) Wow, you weren't kidding. It is much faster than before. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora 21 lets me install packages without root
On Sun, 2014-10-19 at 23:34 -0700, James Patterson wrote: > I am in the wheel group, and if I type: > > nethogs > > then I can install nethogs without any additional authorization. This is > on a freshly booted machine where sudo has not been run. > > Should this be marked as a blocker? > https://bugzilla.redhat.com/show_bug.cgi?id=1153005 > This was approved by FESCo last year. As you noticed, you're in wheel, which lets you do lots of privileged things without typing any password (and many other things with your own password instead of the root password). If you don't want this behavior, you can just remove yourself from wheel. Carry on, Michael signature.asc Description: This is a digitally signed message part -- 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Fri, 2014-10-31 at 15:00 +0100, Nikos Mavrogiannopoulos wrote: > > We should work with the upstream OpenSSL and the GnuTLS projects, > and > > motivate them to implement more advanced path building. This would > be a > > long term project. > > Is there some issue with gnutls in F21? As far as I understand it > should > work as expected with the certificates removed. It works as expected in the sense that GnuTLS can no longer handle major web sites like Amazon and Kickstarter, this being the natural consequence of removing a root before the certificates issued by it have expired signature.asc Description: This is a digitally signed message part -- 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Fri, 2014-10-31 at 15:53 +0100, Nikos Mavrogiannopoulos wrote: > Are you sure that this is the case with the current package? My F21 > can > no longer connect to network to test, but gnutls in it should > reconstruct the chain similarly to what nss does (not very similarly > to > be precise but the end result should be the same). If it is not the > case > please report it as bug and I'll check it out. No, I haven't tested this in a month or two. If there's been recent work on NSS compatibility, that's awesome. Complicating the matter is that these pages sometimes work and sometimes don't (CDN magic I suppose) so we really have to rely on bug reports to know if there's breakage, and we won't get those unless the compat certificates are removed (which I certainly don't suggest). Thanks, Michael signature.asc Description: This is a digitally signed message part -- 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Fri, 2014-10-31 at 16:28 +0100, Kai Engert wrote: > I confirm that using GnuTLS 3.3.9-2.fc21 on Fedora 21 testing, > with ca-certificates-2014.2.1-1.3.fc21, > and ca-legacy set to disabled, > the command > gnutls-cli -p443 www.amazon.com > reports a trusted certificate. This isn't a recent change, see [1]. I presume Amazon is most likely still broken in Epiphany (when these roots are removed) as there's been no action on [1], where we decided that gnutls-cli accepted www.amazon.com because it uses certs if they're valid for either email or TLS, whereas GLib only uses certs if they're valid for TLS. Note that due to CDN magic, sites like Amazon load lots of subresources like images and CSS over connections using unrelated certs, so a more reliable test is to actually open the web page in a browser. P.S. To both Kai and Nikos: thanks for all your effort on this matter. A couple months ago I was quite worried, but now I expect things will turn out fine. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1134602 signature.asc Description: This is a digitally signed message part -- 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: Suggested Freeze Policy change for Fedora 22+
This policy change seems like a really good idea. Thanks for working on it, Stephen. signature.asc Description: This is a digitally signed message part -- 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: Join to Mozilla Location Service in Fedora
On Thu, 2014-11-06 at 19:33 +0530, Sudhir Khanger wrote: > How do I benefit from broadcasting my location? You don't. When a web site requests your location, your browsers prompts you to decide whether or not you want the site to have your location. It's not a broadcast to random sites. For example, a voter's guide might use your location to determine which electoral districts you live in. signature.asc Description: This is a digitally signed message part -- 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: downgrade version of gthumb in fedora 21 final?
On Thu, 2014-11-06 at 13:13 -0800, James Patterson wrote: > Hi, > > Is it too late to downgrade gthumb in Fedora 21 to 3.2.x? > > The version in Fedora is really slow. I posted a bug with more info: > https://bugzilla.redhat.com/show_bug.cgi?id=1161052 I agree that should be downgraded in F21 and possibly in rawhide as well. Since gthumb does not follow the GNOME release schedule, we shouldn't push unstable versions of gthumb to rawhide. I suspect it's being picked up by mclazy signature.asc Description: This is a digitally signed message part -- 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: downgrade version of gthumb in fedora 21 final?
On Fri, 2014-11-07 at 08:52 +, Richard Hughes wrote: > No? We push unstable GNOME to rawhide all the time; or is this more of > a case where we're worrying that a stable gthumb won't be available > before F22 is due? Exactly; since that's what happened for F21, there's a reasonable chance it will happen in the future as well, if not for F22 (which seems quite possible), maybe F23. With most of GNOME, we know when the next stable release will be, and there's no harm in pushing unstable versions so that they get testing. That's not the case with gthumb. I'm confused why they're not following the GNOME release cycle, but that's their choice, and the reasonable consequence is that they get less testing in rawhide so we don't have to gamble on whether or not we'll need to do a downgrade and +epoch or choose to leave it unstable. (In this case, the revert is clearly the correct choice as upstream has said we should not ship 3.3. Anyway, this vindicates the WG's choice to stick with Shotwell for the time being, as gthumb 3.2 really is a huge downgrade) signature.asc Description: This is a digitally signed message part -- 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: Yum-utils and DNF
On Mon, Mar 2, 2015 at 7:55 AM, Michael Mraka wrote: Hi developers, I'm trying to finish port of yum-utils scritps to DNF Hi, thanks for working on this. One request: when you get to debuginfo-install, can you please change it to not disable the debuginfo repository when it's done? Currently PackageKit leaves old debuginfo packages unchanged when it updates the packages they correspond to, which is annoying, and ABRT does not seem to do so either, which is not fun for anyone. That's "by design" since debuginfo-install leaves the debuginfo repository disabled, and of course PackageKit isn't going to look for updates from a repo that's disabled. An alternative would be to enable this repository by default. I guess it's currently disabled by default to make yum go faster, but that mostly makes sense for those who don't have any debuginfo installed. Michael -- 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: Yum-utils and DNF
On Mon, Mar 2, 2015 at 1:37 PM, Igor Gnatenko wrote: Hi, I created this plugin. I think I will create something like yum plugin auto-update-debuginfo, i.e. if at least one debuginfo package installed - it will enable debug repos. Well I don't see why it needs to be done in a separate plugin, but whatever. Thanks a bunch! :) -- 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: Questions about font packaging, hinting and non-responsive maintainer process
On Thu, 2015-03-05 at 02:03 +0100, Kevin Kofler wrote: > Are those hinting instructions manually tuned or autogenerated with > ttfautohint? If it's the latter, there's no value in them because Freetype > already uses essentially the same autohinting algorithms ttfautohint uses, > ttfautohint was developed to provide a similar experience for platforms > without such a smart autohinter. But if they're manually tuned, then the > hinting instructions can be useful, depending on how well and how completely > the work was done. (If only a small percentage of the characters are hinted, > it will only degrade the experience because the presence of hinting bytecode > makes Freetype disable the autohinter for the whole font.) Sounds like Kevin knows what he's talking about. I will just add this: GTK+ (all GTK+ programs not just GNOME ones!) has a setting for hinting style: choices are None, Light, Medium, and Full. None obviously means no hints. Light means we ignore the font's native hints and use the freetype light autohinter. Medium and Full both use the font's native hints. Medium is the default on Fedora (but not on some other distros), so hints *are* useful by default. (Unless they are bad hints. Slightly ironic that Cantarell looks better with the autohinter.) signature.asc Description: This is a digitally signed message part -- 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)
On Thu, 2015-03-05 at 10:41 -0500, Adam Jackson wrote: > False. It's entirely reasonable for a product to mandate an > appropriate > security policy, so until and unless we move account creation entirely > to firstboot, it's something the installer will have to expose. For Fedora Workstation, we have already done that with gnome-initial-setup. Many of us would like to see Anaconda stop offering account creation. (Obviously that only applies for Workstation.) signature.asc Description: This is a digitally signed message part -- 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)
On Thu, 2015-03-05 at 09:12 -0700, Kevin Fenzi wrote: > * gnome-keyring? gnome-initial-setup and gnome-control-center. See: https://bugzilla.gnome.org/show_bug.cgi?id=735578 https://bugzilla.gnome.org/show_bug.cgi?id=744735 gnome-keyring would need modified if we want to enforce password strength on e.g. every web site the user wants to save a password for... that would probably reduce security overall as it would discourage the user from using gnome-keyring. 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). This is an unfortunate situation that stems from differing requirements. I don't believe a stronger local password makes the user much safer, and have yet to see arguments to the contrary. Michael signature.asc Description: This is a digitally signed message part -- 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.
* Case 2: The attacker doesn't have physical access to your computer.
The user account password is irrelevant.
--- This is a pretty simple argument, can anyone point out a flaw? ---
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. 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. Maybe
someone else has a good idea here.
What if the attacker is not after any files on your computer, but just
your password so that he can reuse it somewhere else? In that case,
password strength still doesn't matter: if he can see the hash of your
password in /etc/shadow to try cracking it, he has already pwned you and
might as well log your keystrokes.
If the attacker is unskilled and doesn't know how to boot a live image,
and the password is *exceedingly* bad ("123", "alice", "mcatanzaro"
etc.), then it would matter if the attacker could guess it. I personally
see little harm in taking the ball away from those who'd use passwords
like those.
Possibly there is something I have missed -- if someone can set me
straight as to a safety issue I am missing, that'd be dandy -- but I for
one have yet to see an argument that the strength of the password
matters at all!
Now, enforcing a strong *disk encryption password* and turning on disk
encryption by default (at least for laptops): that would be some actual
security. :)
Michael
signature.asc
Description: This is a digitally signed message part
--
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
Hi! On Fri, 2015-03-06 at 23:01 +0100, Björn Persson wrote: > or if the attacker snuck into your room when you left it to fetch some > coffee, and needs to unlock your console, implant a backdoor and sneak > back out before you return, or otherwise can't reboot your computer > because you would notice it, Well... yes, I suppose if you've left your computer on and locked, and the attacker wants to make sure you do not notice the reboot, or wants to get a RAM dump that would be lost when shut down (e.g. for my gnome-keyring passwords), then there is some benefit, but to a quite limited extent IMO: the attacker is still limited by the speed at which PAM and gdm allow you to try logging in. Every guess takes something like three seconds. So I think a weak password suffices. > In the previous paragraph you wrote that it does matter. It seems that > what you're actually arguing is that the threshold should be very low. Personally, I'd be fine with the password strength check if the threshold was very low, but my proposed threshold is *way* lower than libpwquality can be configured to accept. Different thresholds could make sense for different products. Obviously many other folks want it completely gone. Changing libpwquality would be quite desirable so we can close the upstream bugs in gnome-control-center and gnome-initial-setup. Michael -- 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)
On Fri, 2015-03-06 at 19:40 -0500, Miloslav Trmač wrote: > Consider a client enrolled in AD/IPA. I agree. We can meet both sets of goals with modifications to libpwquality to allow a *dramatically* weaker default configuration, and then a corporate deployment can set of pwquality.conf however it likes. We could even package different configuration files. -- 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 19:25 -0500, Miloslav Trmač wrote: > 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. Wow, I had no clue it was that good. OK, so making one guess at the user account password every ~three seconds would not be an unreasonable attack, once you've stolen the computer, given how slow it would be to attack LUKS. I had incorrectly assumed that the difference in speed would be orders of magnitude. Still, this is not a realistic threat for most users, and it would take forever to attack either way, so this really just convinces me that I can be safe with a much weaker disk encryption password than I had previously imagined. :) -- 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 19:35 -0500, Miloslav Trmač wrote: > 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 doubt anyone will argue against this. :) > 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? Eh, well by my logic they are both so closely-related that it's nonsense to treat them differently... but that comment was more a wishful "somebody please fix VNC or rewrite history" than anything. 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. I wonder how well FreeRDP is coming along -- 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
On Mon, 2015-03-16 at 15:25 -0400, Stephen Gallagher wrote: > Other examples might be preview releases of certain software that are > not yet stable enough to be in Fedora proper or whose installation > might be too disruptive during a stable lifecycle. Like for example > the recent GNOME 3.12 repositories for Fedora 20 users since we had > the long cycle. This is a bad example IMO. We are not set up to handle coprs that include essential system packages. If you try to remove the gnome-3.12 copr with gnome-software, it just uninstalls your desktop environment and leaves you with a broken computer. Installing a single application that's not in Fedora from a copr is one thing, or a newer version of an application, but not if they are core system packages. -- 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: OpenSSL MD5 verification disabled?
Hi, I don't have any comment on the issue for your particular software package, since I don't know how important the security of the TLS is for that package and I'm not familiar with your compatibility needs. However, I see the following lines in the patch: // Work around ill-considered decision by Fedora to stop allowing // certificates with MD5 signatures It's not an ill-considered decision. Researchers first created a certificate collision -- a fake cert that's valid for the MD5 signature that a CA put on another cert -- in *2008*. You can't pretend these are secure in 2015. If you want to accept MD5 certificates, which might make sense depending on your compatibility needs, keep that in mind. It's certainly better than no TLS at all, but won't stop a good attacker. MD5 certificates were phased out years ago, and blocking them does not cause any compatibility issues for certificates from real CAs anymore. The logbook site should use SHA-256 instead of MD5. (Note that SHA-1 is being phased out too!) Michael -- 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: Captive portal detection on wired connections - bug or feature?
On Wed, 2015-03-25 at 21:02 -0600, Kevin Fenzi wrote: > This was most likely caused by some issues with out proxy servers this > evening. We were adding 3 new proxy servers into the rotation and there > were some config issues with some of them. ;( > > This would have only affected some folks in North America sporadically, > (when they happened to hit a proxy that wasn't working right) not > everyone. > > Sorry this happened, everything should be back to normal now. I think it would make sense to do a second ping to some other server if the first one to fedoraproject.org fails, for robustness. Maybe to redhat.com, or something that should never be down like google.com (my vote), or to someplace that promises not to track users, like duckduckgo.com (hardly matters much for a connectivity check?). -- 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: [GSoC'15] Btrfs content-based-storage mode
On Thu, 2015-03-26 at 22:30 -0400, harshad shirwadkar wrote: > Thanks, and I am on top of it. Will post here, once I upload it to > Google Melange. Hopefully you've done this already, but if not make sure you do so *today* as today is the deadline, and if your application isn't in Melange you haven't applied. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
dnf debug-info-install
Hi, I want 'dnf debug-info-install' to be available by default on Workstation. Right now it lives in the dnf-plugins-extras package, which depends on snapper, which we can't install by default. Can this plugin please move to dnf-plugins-core? Michael -- 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 debug-info-install
On Tue, 2015-04-07 at 14:15 +0200, Vít Ondruch wrote: > Dne 7.4.2015 v 14:09 Michael Catanzaro napsal(a): > > Hi, > > > > I want 'dnf debug-info-install' to be available by default on > > Workstation. > > Sorry for my ignorance, but why it should be installed by default? > > Vít Because gdb recommends you use it whenever it detects that debuginfo is missing. :-) Then the process for figuring out how to install it is unnecessarily complex; you either have to magically know that it's present in dnf-plugins-extras, or else magically know about the yum2dnf man page and scroll to the very bottom of that (which I only found because I ran the old debuginfo-install command, which gdb no longer recommends, so new users won't find it). Much better to just install it by default, IMO. Or make it a dependency of gdb: that would be fine too. (Gosh, another great case for Recommends, if only we were allowed to use Recommends!) Anyway, whatever in dnf-plugins-extras that depends on snapper really ought to move to another package. That is not a reasonable dependency. It tries (and fails) to snapshot my system whenever I run 'dnf', hence I uninstalled dnf-plugins-extras soon after I installed it. Michael -- 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 debug-info-install
On Tue, 2015-04-07 at 12:25 +, Tim Lauridsen wrote: > debug-info-install is in dnf-plugins-core Ah, OK. So two problems: * The yum2dnf man page says the command is 'debug-info-install' but it is 'debuginfo-install'. gdb gets the name right; no change needed there. * The man page says the command is in 'dnf-plugins-extras' but it really is in 'dnf-plugins-core'. -- 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 debug-info-install
On Tue, 2015-04-07 at 15:30 +, Petr Pisar wrote: > Because it's not there: > > ┌──┬─┬┐ > │Original Yum tool │ New DNF command │ Package│ > ├──┼─┼┤ > │debuginfo-install │ dnf debug‐ │ dnf-plugins-extras │ > │ │ info-install││ > > What looks like `dnf debug-info-install', is `dnf debug‐info- > install'. > The character just after `debug' is a Unicode hyphen added when > wrapping > long lines by the groff. It's narrower than ASCII hyphen character. Wow, that was a great problem. :) I think it's fine to leave this as-is, now that the package name has been fixed. gdb will tell people to do the right thing. Michael -- 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: Making 3rd party gstreamer codecs work in F22
Telling users to install a F21 repo in F22 sounds like a recipe for disaster. Should we really make it easier to do that? We could point users towards Fluendo's MP3 gstreamer plugin in the meantime -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Heads-up: icedtea-web in comps
Hi, I've removed icedtea-web from the firefox group in comps for F23 (not F22). If icedtea-web is installed by default in your spin and you want to keep it in F23, please add it into your spin's group. This is so that we can keep the firefox group as optional in the gnome-desktop- environment category without pulling in yucky icedtea-web automatically. Note: There should be no user-facing change except when performing a netinstall and selecting GNOME Desktop Environment. Fedora Workstation already did not include icedtea-web. Michael -- 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: RFC: LiveUSB Creator Revamped
On Thu, 2015-05-28 at 14:31 +0200, Martin Bříza wrote: > Also, to see it without actually installing it, there's just a little > bit > outdated screencap: > https://mbriza.fedorapeople.org/liveusb-6.ogv That looks quite good! I have just one comment: the < Back, Write to USB disk, Cancel, and Write to disk buttons belong in a header bar, at least when running in GNOME. -- 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: fedup for F23 and beyond
On Thu, 2015-05-28 at 14:39 -0400, Przemek Klosowski wrote: > Do you think the tech could stabilize enough to obviate the first > reason? The 6-month workflow cadence remains a good idea, of course, > but could result in a major offline upgrade, instead of an entire > new distribution. I think we're already at the point where -- at least for Fedora Workstation (not sure about Server/Cloud), and except for infrastructure issues -- we can stop branding our releases with a version number, and simply have a particularly big offline update every six months. Behind-the-scenes, we still have the six-month cycle, but this is hidden to users. They get Fedora and it's just Fedora, not Fedora 21 or Fedora 22. People stop complaining about the 13-months of support that isn't long enough for them: we wouldn't have that short support window anymore, instead there is *indefinite* support so long as you take your monthly QAed updates pack (five small updates packs, then a big updates pack, then five smaller ones, then a big one, ...). This is the model Windows is moving to, and it makes a lot of sense to me. Michael -- 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: fedup for F23 and beyond
On Thu, 2015-05-28 at 15:05 -0600, Kevin Fenzi wrote: > With timed: you don't get the newest thing, but switching to the new > stuff is more on your schedule. You can ignore the new release for a > while and still get bugfixes/security updates until you are ready to > do > the upgrade. I should add one more thing: in my vision, applications are always updated, period, and that's more important than anything else. We have to do that no matter what, or people will start leaving Fedora for Ubuntu Snappy Whatever which is supposed to arrive real soon now. They're going to have a stable OS with up-to-date applications (not considered part of the OS!), and we need that too to remain competitive. -- 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: fedup for F23 and beyond
On Thu, 2015-05-28 at 17:11 -0600, Stephen John Smoogen wrote: > Good luck with that vision. I would buy into it a bit more if this > wasn't the same chestnut dragged out every couple of releases to > somehow motivate us to accept whatever big OS change is being pushed. > It has become the "Cry Wolf" story and while eventually the wolf eats > the flock... it does so because no one believes the criers anymore. > Please, come up with a better story than people will drop us for > Ubuntu because none of the changes we have done have stopped that > from > happening when it has happened.. and none of them have made us > overtake Ubuntu in the last 8 years. The difference this time is that our primary competitor is doing it in the near future [1], and we have someone actively working on competing technology [2]. At least for Fedora Workstation, we cannot head towards a future where all of our applications are older than what Ubuntu is shipping. That's untenable for us. [1] http://www.linuxjournal.com/content/more-stable-future-ubuntu [2] https://lis ts.fedoraproject.org/pipermail/desktop/2015-May/012362.html -- 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: fedup for F23 and beyond
On Fri, 2015-05-29 at 09:39 -0700, Gerald B. Cox wrote: > I'm failing to connect the dots here... snappy is a different > packaging paradigm with some advantages > and disadvantages; but how exactly does it ensure that distributed > packages are newer? Isn't that > a function of the packager? The point is that you can update to the newest versions of applications as they are released upstream, without having to worry about whether there could be incompatibilities with system libraries. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New ABRT CLI
On Tue, 2015-06-02 at 15:45 +0200, Richard Marko wrote: > Hi, > > over last two weeks I completely rewrote abrt-cli to make life easier > for users and developers. > > It now supports tab completion and few new commands like abrt gdb and > abrt debuginfo-install. Without any arguments these commands will use > the last crash that occurred on your system. Ooooh, 'abrt gdb' in particular sounds like fun. :) Michael -- 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: virt-manager - libappindicator-gtk3 - remmina
On Thu, 2015-06-04 at 03:24 +0200, Kevin Kofler wrote: > libappindicator is now (since Fedora 22) also REQUIRED for GTK+ > system tray > applets to work under KDE Plasma. (Plasma 5 no longer supports the > legacy > XEmbed-based system tray protocol that the builtin GTK+ classes > implement.) Hey, that's awesome, congrats on killing XEmbed. I wish GNOME would do that as well -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 2015-06-12 at 13:00 -0400, Matthew Miller wrote: > I hope we can get a design for this which integrates better with > GNOME > Shell and the existing network icon there. Well we're just not going to ship this in Workstation if it breaks NetworkManager's connectivity checking, nor will we ship anything that displays a system tray icon (that looks like a debugging tool, not something users should ever see). But there's plenty of time left before Fedora 23, and it sounds like several people are trying to fix these things, so hopefully that will all be taken care of and we'll be able to spotlight the local DNS resolver as a major new security feature come release time. Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 2015-06-12 at 12:17 -0500, Dan Williams wrote:
> > dnssec-trigger prompts the user with a choice of "allow insecure
> > DNS" or
> > "cache only mode". The latter means "no new DNS and use what's
> > already
> > in the cache only".
>
> Yeah, and the interaction story here has been controversial for a
> long
> time. The GNOME team certainly has ideas about how it should work,
> which are partly shown by the current hotspot/portal implementation
> in
> GNOME Shell. I'll let them discuss these ideas since NM is not
> involved
> in the higher-level UI story here, just the mechanics of providing
> "might this be a portal" to any NM client, GNOME Shell included.
Hi. In general, prompts along the lines of "do insecure thing [yes]
[no]" are a big no-no. You should either always do the insecure thing
(if it really must be allowed) or never do the insecure thing
(preferably), but prompting the user to make a confusing security
decision is not OK.
In this case I assume always failing the connection is the right thing
to do, as to do otherwise would defeat the purpose of this feature. If
we could automatically display some very basic troubleshooting steps
("call your ISP and tell them xyz"), that would be good too. But I
presume it's unlikely that every workaround will fail and the user is
stuck without DNS? Hopefully that would be rare. If it's not and the
user really must be given a choice to allow insecure DNS, then maybe
the world just isn't ready for DNSSEC yet
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 2015-06-12 at 11:19 -0700, Andrew Lutomirski wrote: > It wouldn't really have to be Firefox, but getting the browser chrome > right to avoid trivial phishing attacks is critical, and all real > browsers already do that fairly well, whereas the simple embedded web > views (e.g. gnome-shell-portal-helper) get it nearly 100% wrong. Hi, it sounds like we have a problem to fix in gnome-shell-portal -helper. What specifically are your requirements for the browser chrome? I figure as long as the window title is something along the lines of "Connect to wireless network" and the hotspot can't change that, then we should be good? We could also put a short explanation of what is going on in a GtkInfoBar to make it really stand out. I guess the goal is to make the chrome distinctive enough that a user stops to think "something is not right, don't enter password" when the captive portal helper appears and displays google.com. FWIW the tech used for GNOME apps that need a web view is WebKitGTK+. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
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. It'd be nice to not show http://www.gnome.org (the test URL we load, expecting to be hijacked) if the portal decides not to redirect you to a new URI (not sure how common that is), but I think we will have to or we can't fix this > I think the UI should look like a real browser except that it should > clearly indicate that it's a "Log in to wireless network" browser in > addition to showing a standard URL bar. > > https://bugzilla.gnome.org/show_bug.cgi?id=749197 Can you please CC me on that bug? I didn't know GNOME Bugzilla even had private bugs. :D > > FWIW the tech used for GNOME apps that need a web view is > > WebKitGTK+. > > Can that provide real chrome? The web view is a GtkWidget: you pack it like any other GtkWidget into your hierarchy, and put your own chrome around it. In this case, a URL bar would not make any sense since we don't want the user changing the URL; we'll probably want to display an unmodifiable URL alongside a security indicator. -- 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 Sat, 2015-06-13 at 14:36 -0400, Paul Wouters wrote: > using www.gnome.org is wrong. For one, you cannot guarantee they > won't > end up using some redirect and than the captive portal would fail. I don't get it: what is wrong, what would fail? We expect them to replace the contents of www.gnome.org with either their own content, or else a redirect someplace else. > Second, the TTL for that DNS entry is not 0, so it will get cached > and > cause wrong probe results later on. > > There is a good reason we started hotspot-nocache.fedoraproject.org. Hm... the captive portal helper loads www.gnome.org but it only runs after NetworkManager has decided there is a captive portal. We can make this URL configurable at build time if there's really a problem, but I'm not sure there is, since it's not used for NetworkManager's connectivity check (which is what triggers us to start the captive portal helper, and what decides that we have full Internet access and closes it). For the connectivity check, NetworkManager uses https://fedoraproject.org/static/hotspot.txt defined in /etc/NetworkManager/conf.d/20-connectivity-fedora.conf. So... I guess that is not good, and we should switch that to use hotspot -nocache.fedoraproject.org instead? -- 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 Sat, 2015-06-13 at 15:54 -0400, Paul Wouters wrote: > If the captive portal uses the system's DNS, and the system has > cached > www.gnome.org from when you were on a previous network, your captive > portal check might use a cached DNS resolve and try to use an HTTP > connection to a blocked IP address, because the local forged DNS > answer > to the local hotspot IP never got triggered. Thanks. I am still trying to understand this fully. I assumed the portal would hijack TCP connections, but if the portal uses DNS hijacking only and does not hijack TCP connections to the real www.gnome.org, and we attempt to open a TCP session to the real www.gnome.org, and the portal is only expecting us to visit a different host due to its DNS hijacking, then I understand that we're out of luck and the portal's login page will never show. OK, I've followed that far. There is one thing I don't understand. Surely the above is exactly what will happen if you were to get stuck behind a captive portal with Firefox or any normal browser? But portals still work reliably for users. So either the browsers are doing a connectivity test similar to what you described (to a host with a DNS TTL of 0) and we have to do it too, or the portals are prepared to hijack TCP connections and not just DNS and we have no problem, or the portals just don't work reliably for browsers and portal-helper is an opportunity to fix that. Right...? Anyway, once I understand this properly, I will file a bug upstream (or if you have a GNOME Bugzilla account, it would be better if you do so, to be CCed on responses). Thanks for catching this issue. Michael -- 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: Packaging Guidelines for Applications using Git Submodules
On Wed, 2015-06-17 at 09:24 +0200, Tomas Hozza wrote: > > I'm trying to figure out the best way to handle the situation where > a > > project decides to use submodules in Git. The archive generated > doesn't > > incorporate the submodule files. Maybe this is a GitHub-specific problem. If the submodule files are not present in the archive, then archive cannot be intended to be used -- it's just a consequence of pushing a tag to GitHub that a tarball of the repo contents gets automatically generated. Projects that host real tarball releases (anything you get from GNOME, for example) will include the submodule in the archive. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Tue, 2015-06-23 at 18:43 +0200, Tomas Hozza wrote: > I hope that GNOME Shell somehow only displays the state provided by > NM. > Bastien, please correct me if I'm wrong and please elaborate on the > details of what the functionality does (e.g. if you launch a new > browser > or so). Yes, that's correct. If NetworkManager's ConnectivityState is NetworkManager.ConnectivityState.PORTAL, then we launch a small (250 lines of code) GTK+ app with a WebKitWebView [1][2]. I expect that as long as NetworkManager's existing connectivity API is not broken, GNOME should be fine. [1] https://git.gnome.org/browse/gnome -shell/tree/js/ui/status/network.js#n1964 [2] https://git.gnome.org/browse/gnome-shell/tree/js/portalHelper/main.js -- 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: Btrfs as default filesystem for Fedora 23?
On Tue, 2015-06-23 at 19:07 -0600, Stephen John Smoogen wrote: > My apologies.. my tone was not helpful. You are correct that asking > here is where to start. I think the groups who would be able to help > answer would be > > 1. Kernel team > 2. QA team > 3. Anaconda team > 4. Workstation/Server/Cloud or just one if it were to be only on one > product. We're unlikely to move forward with btrfs for Workstation until the kernel team changes its recommendation. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO Elections - June 2015 - Results
On Mon, 2015-06-29 at 13:47 +0100, Tom Hughes wrote: > Probably not surprising given the silly way the election was > announced... It certainly disenfranchised me. > > The problem you see is that the announcement was sent out on 20th > June, > but you couldn't actually vote then, because voting didn't open until > > the 22nd. So you couldn't just go and vote when you got the > announcement > but instead you had to remember to do so a few days later. I would definitely prefer the announcement to take place once the balloting has actually opened. I had to put the elections on my to-do list; otherwise, I would have forgotten as well. -- 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: Standardized Passphrase Policy
> I understand that as a request to write some simple how-to-use > document > for libpwquality and not a request to drop it altogether and use > instead ... what? > > Note also that libpwquality is highly configurable and for things > that > can not be configured currently a configuration can be easily added. We discussed this a while back in the Workstation WG [1]. We'd be happy with libpwquality if we could configure it to allow weaker passwords than pwquality.conf currently allows for. This feedback was supposed to make it to you, but I'm not sure if that happened; we don't track action items as well as we should. Michael [1] http://meetbot.fedoraproject.org/fedora-meeting/2015-04 -01/workstation.2015-04-01-15.00.log.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Tue, 2015-06-30 at 11:24 +0200, Tomas Hozza wrote: > The thing is that some information are unrelated to NM. There is no > reason to push all information back to NetworkManager, since its role > is > explicitly defined - manage network connections and leave the DNS > resolution and configuration up to different tool. I'm not sure I agree with that, from a desktop developer perspective. It's very convenient for GNOME (and probably also KDE) for NetworkManager to be the one-stop shop for network management. It already allows you to configure DNS anyway (in GNOME, under Network -> hidden gear menu in the lower right -> IPv4 or IPv6) so there has to be some level of integration to keep that working. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Tue, 2015-06-30 at 14:23 +0200, Tomas Hozza wrote: > Except that this is exactly what we DON'T want to do. DNSSEC is an > extension of DNS and it can be used even without the need for the > whole > Internet to be signed. We want to use it even if the network-provided > DNS resolvers don't support DNSSEC. I'm confused on one point: why would the user ever want to turn off DNSSEC validation (except to get past a for captive portal)? It sounds like you have no shortage of safeguards in place to make sure this always works: for it to break the user would have to be on a network that doesn't support DNSSEC, that blocks VPN, with the Fedora infrastructure down, right? I think it's OK to fail connections in that case (provided we have a story for captive portals). What we basically do not want is to give the user an option for turning a security feature off. -- 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: Supporting hibernation in Workstation ed., draft 1
On Sat, May 30, 2020 at 1:36 am, Chris Murphy wrote: I don't know whether or when there will be any changes to UI. I think it's already conditional now. The option to hibernate appears in the GUI on my test system that can hibernate and doesn't appear on the systems it's not supported on. I think we don't expose hibernation in the UI at all, except as low-power action to take when out of battery. (In that case, attempting to hibernate, risking data loss, is better than power off for guaranteed data loss.) Do you see it anywhere else...? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Supporting hibernation in Workstation ed., draft 1
On Sat, May 30, 2020 at 4:23 pm, Chris Murphy wrote: I only see it in the "Power Button Action" menu. OK... I stand corrected. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Install gparted to Live installers
I don't think we actually have the technical capability to ship it in live media without also installing it by default on the installed system. It currently has to run as root, which is not acceptable, so would require some work to split out privileged operations into a separate backend process and use polkit for authentication. I think it would make more sense to focus on improving Disks to do what you need rather than rewriting GParted. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy wrote: That is the plan, otherwise the swap-on-zram device probably never gets used. And then its overhead, which is small but not zero, is just a waste. I thought the plan was to get rid of the disk-based swap partition, since it has an unacceptable impact on system responsiveness? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Datacenter move days 3 and 4
On Fri, Jun 12, 2020 at 9:47 am, John M. Harris Jr wrote: Why? John, this was a thread about a data center move. There was no need to change the topic. :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation
On Tue, Jun 16, 2020 at 2:03 pm, Kamil Paral wrote: The person proposing this Change should supply some video showcasing this, or a very detailed description, otherwise people will have very varying ideas of how this works and looks. $ sudo dnf install f32-backgrounds-animated Select the animated background in gnome-control-center and see for yourself how it works. :) It's an XML file that describes state transitions between static images. Usually only the colors vary, transitioning to darker colors at night, lighter colors in the morning, standard colors during daytime. Fedora has supported this for as long as I remember, we just haven't used it by default in a long time. (I think we actually shipped an animated background by default once before a while back, though it's been long enough that I don't remember that for certain.) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation
On Tue, Jun 16, 2020 at 2:41 am, Kevin Kofler wrote: "select a different frame"? Does that imply that you want to ship the full animated package on all spins, even those that do not support animated backgrounds, and let each spin pick its own preferred version out of the list (because all will be shipped anyway)? No, see the existing f32-backgrounds.spec for how the subpackaging works. Animated backgrounds are in a separate subpackage that spins do not need to install. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
