Re: Gating feedback from early adopters after almost 2 years: It doesn't seem to work
Hey Miro, Sad to hear that it's been so rough. On Wed, Apr 7, 2021 at 9:59 AM Miro Hrončok wrote: > Hello, > I was torn whether to share this here or not. I don't want to be the one > who > always complains about things, but at the end I've decided that without > honest > feedback, there cannot be progress (and I've realized I already am that > guy). > > Please don't take this feedback personally, I know that building things is > hard. > I don't criticize people, but the tools. > > Almost 2 years ago, we've decided to be the early adopters of gating in > Fedora > with the python-virtualenv package: > >https://src.fedoraproject.org/rpms/python-virtualenv/c/66b7533376f > > Gating has proved more problematic than useful. It almost never works > reliably, > the problems are impossible to decipher and/or debug. Too often we had to > ask > for a CI-expert human intervention or straight out waive the results. > > The humans we've contacted were always very friendly, helpful and they > were able > to solve our issues. However, human-operated CIs unfortunately don't scale > very > well. > Heh heh. At first, we assumed the issues will get ironed out with time, but there > seem to > be no visible progress. > > Moreover, the gating caught 0 issues, because we already test our changes > via > Pull Requests. > I'm not sure if others have similar experience, or if we just got unlucky :( > Martin Pitt recently posted a blog post about how he's been using the same tests and environments upstream in Pull Requests + downstream in Fedora gating. He also talks about "Fedora Gating woes" there. Perhaps similar concerns and pragmatic solutions. https://cockpit-project.org/blog/fmf-unified-testing.html Cheers, Stef > > After a very bumpy ride, we've now removed the (quite incomprehensible) > gating > config, because frankly, it just gets in the way: > >https://src.fedoraproject.org/rpms/python-virtualenv/pull-request/39 > > We will continue to run the CI in pull requests (which isn't perfect > either but > at least we have redundancy and we see visible progress there over time) > and to > run tests in %check (which works perfectly, but has many unfortunate > limitations). > > Let me be 100% clear: The situation wrt CI is complex and brings many > interesting challenges, but if I compare it with the dark ages before > that, I > would not trade. Thank you everybody for making Fedora a better place to > contribute to. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > CI mailing list -- c...@lists.fedoraproject.org > To unsubscribe send an email to ci-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/c...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Stef Walter (he / his) Linux Engineering Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: yubico-piv-tool & p11-kit
On 03.12.2016 13:50, Nathaniel McCallum wrote: > So apparently yubico-piv-tool ships $libdir/libykpkcs11.so*, but this > doesn't get picked up by p11-kit by default. I suspect it has gone > unnoticed largely because for most crucial operations the opensc > module also works with Yubikeys. However, this is not true for all > operations (in particular, in my case, key creation). > > How can we make this happen? Is there some intentional reason Yubico's > PKCS#11 module has been excluded? p11-kit doesn't look hopefully across the whole system looking for possible PKCS#11 modules :D There's a drop in file that helps p11-kit find it: https://p11-glue.freedesktop.org/doc/p11-kit/pkcs11-conf.html Typically these drop in files are distributed along with the module in an RPM or Deb file. So that may be your first stop for filing a bug: The package in the distro you're using that shipped the above .so file. Hope that makes sense, Stef signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Some analysis on the size of the minimal and Server installs of Fedora 23
On 17.11.2015 02:39, Stephen Gallagher wrote: > (Please keep responses on the devel@ list; I've set it in the Reply-To.) > > To jump right to the premise: The default Fedora Server install is Way > Too Big(TM) and the minimal install (also available on the Fedora > Server install media) is also Too Big. > > I've been trying to do some quick-and-dirty analysis of what is in > these default installations in order to figure out where we should be > focusing our efforts. I'll point out that there are two goals that we > need to keep in mind (and the reasons behind them) in order of > increasing importance: > > 1) Reduce disk space usage. While disk space on physical devices is > becoming trivially cheap, disk space on Cloud deployments and rented > virtual servers is still comparatively very expensive. We really want > to minimize the amount of space that we use for Fedora so that users > can fit their applications (the stuff they actually care about) into > the remaining space without being forced to buy a larger storage > allotment. > > 2) Reduce maintenance efforts. Every additional piece of software on > the system (referred to hereafter as "packages") increases the > maintenance burden on an administrator. Universally, administrators > prefer to have the smallest number of packages to maintain for a > variety of reasons: > * Limiting update churn. The more packages on the system, the more >often that one will need to run updates. > * Limiting security exposure. Every package on the system is another >potential privilege-escalation point. Keeping this number under >control means a reduced likelihood of a catastrophic breach. (The >actual risk here is impossible to quantify, but it can be assumed >that less code == less potential vulnerabilities. > * Non-expert administrators do not always know what is installed on >their systems. This can lead to unintentional breaches as an >admin doesn't realize that one or more services needs to be limited >(such as in the firewall or via SELinux). > > With these two goals in mind, the most obvious approach to improving > this situation would be by reducing the number of packages installed > by default on the Minimal and Fedora Server installs. As a specific > goal of the Server Working Group, we want to aim for a world wherein > administrators will no longer desire to install the Minimal install > and instead will rely on the platform provided by the default Fedora > Server install. They do not do this today because the Fedora Server > installation is considerably larger. I postulate that this is due > primarily to dependency bloat, which is where we should focus our > efforts during the Fedora 24 timeframe. I postulate (but have not yet > confirmed) that there are likely many places where we could replace > Requires: with Recommends: (or even Suggests:) dependencies. In my > ideal world, the difference between a Minimal and Server install would > be identical to installing the same set of packages with Recommends: > on or off. > > > Some highlights of my initial research (with a lot of my raw data in > the tarball attached to this email): > > > == Minimal == > > === Disk Usage === > /boot: 79MB > /: 755MB > > > === Packages === > Total count: 270 > > Largest 10 packages > 14288083: coreutils > 14486819: glibc > 16648994: grub2 > 18024040: kernel-modules > 27253403: systemd > 28453336: python3-libs > 36004297: grub2-tools > 53295853: kernel-core > 86298752: linux-firmware > 125178630: glibc-common > > 10 Longest dependency chains > b'kbd': 116 > b'dnf-plugins-core': 117 > b'plymouth-scripts': 121 > b'plymouth': 121 > b'firewalld': 122 > b'grub2-tools': 125 > b'grub2': 131 > b'NetworkManager': 138 > b'dnf': 144 > b'dnf-yum': 145 > > > > > > > > > == Server == > > == Disk Usage == > /boot: 97MB [1] > /: 1.2GB > > > === Packages === > Total count: 603 > > Largest 10 packages > 18590064: samba-client-libs > 22484896: docker > 25209005: python-libs > 27253403: systemd > 28453336: python3-libs > 30242477: libicu > 36004297: grub2-tools > 53295853: kernel-core > 86298752: linux-firmware > 125178630: glibc-common > > 10 Longest dependency chains > b'abrt-addon-python3': 170 > b'abrt-retrace-client': 171 > b'abrt-addon-pstoreoops': 171 > b'abrt-addon-ccpp': 183 > b'abrt-addon-vmcore': 190 > b'rolekit': 196 > b'abrt-cli': 214 > b'cockpit': 216 > b'freeipa-client': 249 > b'fedora-release-server': 252 > > > Additional Package Groups > (These are the package groups we include above and beyond "Minimal > Install")[2] > > I'm not including package sizes here since most of the space comes > from their dependencies. > > * server-product > - fedora-release-server: dependency chain length: 252 >- cockpit: see below >- rolekit: see below >- systemd: chain 104 > - chrony: 468KiB, chain 111 > * server-hardware-support > - lm_sensors: chain 139 > -
Re: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 11:24, Tomas Hozza wrote: On 26.06.2015 17:13, Matthias Clasen wrote: On Tue, 2015-06-23 at 18:43 +0200, Tomas Hozza wrote: Hey, I was out for a week, so this may be a bit of a late reply. As Michael and Bastien already stated, all the GNOME networking UI relies on information gotten from NetworkManager, and we'd like to keep it that way. In particular, NetworkManager has an existing API to inform us about captive portals - if at all possible, you should keep that working. Yes, it should work. We didn't change anything related to that. We just had our own implementation. [...] This boils down to what we need from some new version of the UI that we need to be well integrated with GNOME: 1. Be able to inform user about some situations (Captive portal detected, network blocks all DNS communication, ...) and enable the user to take an action. (This could be possibly done by the notifications system in latest GNOME) - this may be solved also in GNOME already, and may be OK if done technically correctly. Please note my note earlier on NM notifying other services when Captive Portal is detected My perspective on this is that we already have a UI: GNOME shell displays network status, including captive portal. If NetworkManager needs to add a few more connection states related to DNSSEC, we can adapt to that. The thing is that some information are unrelated to NM. There is no reason to push all information back to NetworkManager, since its role is explicitly defined - manage network connections and leave the DNS resolution and configuration up to different tool. GNOME shell also launches a browser when needed for captive portal login. If we need to tweak the way the browser is launched to make it work on a dnssec-enabled system, that should be possible. I was not able to determine if you rely on the system's stub resolver. If that is the case, NM should notify GNOME only after dnssec-trigger switches to hotspot signon mode. 2. Possibly have some indicator showing if the system is in Secure or Insecure state. 3. Enable the user to switch between those two states manually This seems dubious, at best. What does it mean if my system is 'insecure' ? Will my credit card number be stolen ? Will my system be taken over by intruders if I don't disconnect immediately ? Most users will have no idea, and have to treat such a switch either as scary, don't touch or as the fix the internet button. It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 13:53, Bastien Nocera wrote: - Original Message - On 30.06.2015 11:24, Tomas Hozza wrote: snip It means that the site of your bank you are on may not be provided the actual host you should be connected to, but instead by some attacker's. The insecure mode means that you are vulnerable in the same way as the plain DNS is. So you are insecure even now if you don't use DNSSEC without realizing it. Except if your bank is using https and you connected to it that way, and you have unbroken CA roots. and so on ... The combinatorial explosion of states between insecure (someone just stole my money) and secure (the NSA be crying because they can't touch this) ... means you end up with about posibilities to explain to the user. It's not possible to represent all of this in a dialog. We'd have to print a book and mail to to the user. Which means that it needs to be opt-in for us not to have unbreak my Internet buttons in the UI. Once DNSSEC is more widely deployed and we can safely assume that the majority of the Internet is used it, we can toggle it on. Yeah, that's one option. Another is if dnssec-trigger can reliably detect the presence of DNSSEC on a given network, then it could enforce its use from then on. But making the user decide (or showing them a message) every time they connect to such networks is not the way to go. Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On 30.06.2015 16:50, Tomas Hozza wrote: On 30.06.2015 16:07, Michael Catanzaro wrote: On Tue, 2015-06-30 at 14:23 +0200, Tomas Hozza wrote: Except that this is exactly what we DON'T want to do. DNSSEC is an extension of DNS and it can be used even without the need for the whole Internet to be signed. We want to use it even if the network-provided DNS resolvers don't support DNSSEC. I'm confused on one point: why would the user ever want to turn off DNSSEC validation (except to get past a for captive portal)? It sounds like you have no shortage of safeguards in place to make sure this always works: for it to break the user would have to be on a network that doesn't support DNSSEC, that blocks VPN, with the Fedora infrastructure down, right? I think it's OK to fail connections in that case (provided we have a story for captive portals). What we basically do not want is to give the user an option for turning a security feature off. Right. The UI is what people are balking against. Thank you for explanation. In that case we don't need any UI integration for this. Even though we use dnssec-trigger daily on our machines, we wanted to give the user a way to disable the feature if needed without the root access. This is more of a precaution in case something is broken and we didn't know about it. So this should then become a network setting and go into NetworkManager then, as one of its many options, and sit next to other DNS settings? Non-root users can perform limited network configuration (think wifi passwords and friends), so this isn't such a stretch. Stef -- 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
On 26.06.2015 22:53, Kevin Fenzi wrote: On Fri, 26 Jun 2015 16:21:02 -0400 Matthias Clasen mcla...@redhat.com wrote: But passwords and passphrases are not all the same shape or color - the requirements for a password you want to use for ssh login over the internet are quite different from ones for a shared account used by all family members, or a passphrase that you use to protect your diary in your home directory. How does a single common policy make sense for such wildly different use cases ? Your list of applications looks like you are really only interested in passwords for local user accounts, though. If that is the case, please make that clear in the description. Side note: IMHO, we should remove and stop using the term 'password'. It evokes back to the early days of UNIX where you had to choose a 8 character or less 'word' to gain access to something. All our tools can and should use much longer phrases. And yes, you are right there's different needs for different things and I was focusing on local uses. (Local logins, luks, etc) I'll see if I can clarify the change page for that. thanks. [...] The applications involved in this change should be at least: * anaconda - sets initial root and user passphrases/passwords. * passwd - command line utility that changes passphrases/passwords. * initial-setup - sets up users if they were not setup in anaconda. You should add gnome-control-center to this list. Good idea. Will do so. Cockpit too. We use pwscore from libpwquality, FWIW. Stef -- 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: jQuery
On 24.06.2015 02:01, Jan Kurik wrote: = Proposed System Wide Change: jQuery = https://fedoraproject.org/wiki/Changes/jQuery Change owner(s): T.C. Hollingsworth tchollingsworth at gmail dot com jQuery is a fast, small, and feature-rich JavaScript library. It makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API that works across a multitude of browsers. With a combination of versatility and extensibility, jQuery has changed the way that millions of people write JavaScript. Traditionally, a copy of jQuery has been included with every web application that requires it. This change will migrate many of those applications to a shared system copy of jQuery. Both the 1.x branch of jQuery that supports Internet Explorer 6 and the 2.x branch of jQuery that only works with modern web browsers will be provided. I think that as described, this change will cause more harm than good. As both an upstream and a packager of Cockpit I am against it in its current form. With significant extra work (such as CI) perhaps the change could be less harmful, see below. 1. How will compatibility issues be handled? In the case of Cockpit, jQuery forms part of our future plugin API guarantees. The web application loses control of its dependencies, which normally form a intimate part of the app. How much bandwidth do you have to handle such bug reports? 2. Will Fedora have continuous integration running for all applications it modifies in this way so it can detect breakage? Or should upstream ignore bug reports from Fedora versions where their code has been patched, with regards to jQuery? 3. Most modern web applications compress and bundle their resources. For example in Cockpit, we: * Gzip jQuery and all other javascript resources. * Bundle them together with other resources and load them together with other scripts in one HTTP response. You'll find this going on throughout most applications that care about load time or module loading. 4. Many web applications load jQuery from CDN (although not Cockpit, since it can be used with a non-internet connected server). Do you plan to patch these as well? If not, then why are these left out of the scope of the change? Stef -- 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 for integration tests infrastructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22.10.2014 13:43, Honza Horak wrote: Fedora lacks integration testing (unit testing done during build is not enough). Taskotron will be able to fill some gaps in the future, so maintainers will be able to set-up various tasks after their component is built. But even before this works we can benefit from having the tests already available (and run them manually if needed). Hereby, I'd like to get ideas and figure out answers for how and where to keep the tests. A similar discussion already took place before, which I'd like to continue in: https://lists.fedoraproject.org/pipermail/devel/2014-January/193498.html And some short discussion already took place here as well: https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-October/000570.html Some high level requirements: * tests will be written by maintainers or broader community, not a dedicated team * tests will be easy to run on anybody's computer (but might be potentially destructive; some secure environment will not be part of tests) * tests will be run automatically after related components get built (probably by Taskotron) Where to keep tests? a/ in current dist-git for related components (problem with sharing parts of code, problem where to keep tests related for more components) b/ in separate git with similar functionality as dist-git (needs new infrastructure, components are not directly connected with tests, won't make mess in current dist-git) c/ in current dist-git but as ordinary components (no new infrastructure needed but components are not directly connected with tests) How to deliver tests? a/ just use them directly from git (we need to keep some metadata for dependencies anyway) b/ package them as RPMs (we can keep metadata there; e.g. Taskotron will run only tests that have Provides: ci-tests(mariadb) after mariadb is built; we also might automate packaging tests to RPMs) Structure for tests? a/ similar to what components use (branches for Fedora versions) b/ only one branch Test maintainers should be allowed to behave the same as package maintainers do -- one likes keeping branches the same and uses %if %fedora macros, someone else likes specs clean and rather maintain more different branches) -- we won't find one structure that would fit all, so allowing both ways seems better. Which framework to use? People have no time to learn new things, so we should let them to write the tests in any language and just define some conventions how to run them. TAP (Test Anything Protocol) FTW. It really makes sense when you're trying to combine tests from multiple different languages, testing frameworks, etc. Stef -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlRJWOMACgkQe/sRCNknZa/ltQCfcTBBPOIl3fISqjm0j3YUw+TU eSAAoIMo+NSOg/iWf27VQuq0J2rTebT/ =L9uQ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: defining firewalld services
On 03.07.2014 15:39, Rex Dieter wrote:
I'm looking into providing a predefined firewalld service definition for
kde-connect, per
https://bugzilla.redhat.com/show_bug.cgi?id=1115547
Looks like it's as easy as dropping an xml snippet into
/usr/lib/firewalld/services/
I'm also noticing currently that the only package besides fallwalld itself
doing this is cockpit, which includes a %post scriptlet:
# firewalld only partially picks up changes to its services files
# without this
test -f %{_bindir}/firewall-cmd firewall-cmd --reload --quiet || true
Is this the recommended approach? If so, I'll follow this lead, and maybe
start work on drafting some packaging guidelines.
Thomas Woerner would be the one to work out those guidelines.
But to explain ... apparently there are two firewalld environments.
When you install a service file it only affects the installed
environment (used after a reboot) and not the current runtime environment.
This means that a user can't immediately use your service definition in
a command like:
$ firewall-cmd --add-service=cockpit
The command:
$ firewall-cmd --reload
... makes newly installed service files available in the runtime
environment. I guess this is sorta analogous to 'systemctl daemon-reload'.
Stef
--
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: Don't use at_console in DBus policy files
On 06.05.2014 15:36, Richard W.M. Jones wrote: On Fedora 20, I'm seeing this list: /etc/dbus-1/system.d/bluetooth.conf: bluez-0:5.12-1.fc20.x86_64 /etc/dbus-1/system.d/com.redhat.NewPrinterNotification.conf: system-config-printer-libs-0:1.4.3-2.fc20.noarch /etc/dbus-1/system.d/com.redhat.PrinterDriversInstaller.conf: system-config-printer-libs-0:1.4.3-2.fc20.noarch /etc/dbus-1/system.d/com.redhat.tuned.conf: tuned-0:2.3.0-2.fc20.noarch tuned-0:2.3.0-3.fc20.noarch /etc/dbus-1/system.d/connman.conf: connman-0:1.21-1.fc20.x86_64 /etc/dbus-1/system.d/dbus-abrt.conf: abrt-dbus-0:2.2.1-1.fc20.x86_64 /etc/dbus-1/system.d/FirewallD.conf: firewalld-0:0.3.9.3-1.fc20.noarch /etc/dbus-1/system.d/nm-ifcfg-rh.conf: NetworkManager-1:0.9.9.0-38.git20131003.fc20.x86_64 /etc/dbus-1/system.d/nm-user-settings.conf: sugar-0:0.100.2-1.fc20.noarch /etc/dbus-1/system.d/ofono.conf: ofono-0:1.14-1.fc20.x86_64 /etc/dbus-1/system.d/org.fedoraproject.Setroubleshootd.conf: setroubleshoot-server-0:3.2.17-1.fc20.x86_64 /etc/dbus-1/system.d/org.fedoraproject.SetroubleshootFixit.conf: setroubleshoot-server-0:3.2.17-1.fc20.x86_64 /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf: NetworkManager-1:0.9.9.0-38.git20131003.fc20.x86_64 /etc/dbus-1/system.d/org.selinux.conf: policycoreutils-python-0:2.2.5-3.fc20.x86_64 /etc/dbus-1/system.d/wicd.conf: wicd-common-0:1.7.2.4-7.fc20.noarch /etc/dbus-1/system.d/yum-updatesd.conf: yum-updatesd-1:0.9-15.fc20.noarch Thanks! And thanks for the repoquery info. I've filed a bunch more bugs tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=1094121 Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Don't use at_console in DBus policy files
at_console=true (or similar) in a DBus policy file uses pam_console to try to limit sending of messages to a DBus service. This is an old relic from before polkit. Many distros that don't implement it, or implement it completely differently. Last time I heard, kdbus won't support it. NetworkManager has removed at_console from their policy [0] and I've filed some bugs against firewalld [1], setroubleshoot [2], abrt [3] to remove it from the relevant DBus policy files. Is there a good way to grep across the whole of Fedora to see which other packages have at_console in their /etc/dbus-1/*/* policy? Cheers, Stef [0] https://bugzilla.redhat.com/show_bug.cgi?id=979416 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1094745 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1094752 [3] https://github.com/abrt/abrt/pull/816 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
PSA: don't make your polkit policies desktop centric
Many of the polkit policy files services ship in Fedora have lines that look like this: defaults allow_anyno/allow_any allow_inactiveno/allow_inactive allow_activeauth_admin_keep/allow_active /defaults The allow_anyno/allow_any prevents use of the service from remote sessions such as ssh or Cockpit. The poorly named allow_any tag controls the default policy for users logged in from any non-monitor+keyboard session. That is, sessions that don't come from a 'seat'. So unless your service is changing seat specific hardware, you probably want an allow_any tag that is similar or identical to allow_active. For example: allow_anyauth_admin/allow_any If you think this is confusing ... it's because it is. Documentation here: http://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html Some bugs and patches filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1094121 Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: PSA: don't make your polkit policies desktop centric
On 05.05.2014 13:58, Hans de Goede wrote: Hi, On 05/05/2014 11:47 AM, Stef Walter wrote: Many of the polkit policy files services ship in Fedora have lines that look like this: defaults allow_anyno/allow_any allow_inactiveno/allow_inactive allow_activeauth_admin_keep/allow_active /defaults The allow_anyno/allow_any prevents use of the service from remote sessions such as ssh or Cockpit. The poorly named allow_any tag controls the default policy for users logged in from any non-monitor+keyboard session. That is, sessions that don't come from a 'seat'. So unless your service is changing seat specific hardware, you probably want an allow_any tag that is similar or identical to allow_active. Erm, IMHO it should be the same as allow_inactive, if something is not allowed to be done from an inactive state (ie from a switched away session with fast user switching) it certainly should also not be allowed to be done over ssh. Technically you are correct. The best kind of correct. In reality it depends on the service. Some services may want to prevent use when inactive (ie: locked screen) simply for UI reasons, not security. But more importantly allow_inactive has been copy-pasta'd all over the place. For the services I've filed bugs for nobody has really thought about whether it's correct. So yes, if your service makes a distinction about allow_inactive for a good reason, then set allow_any to the same thing. Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: PSA: don't make your polkit policies desktop centric
On 05.05.2014 14:44, Nikos Mavrogiannopoulos wrote: On Mon, 2014-05-05 at 14:21 +0200, Stef Walter wrote: The allow_anyno/allow_any prevents use of the service from remote sessions such as ssh or Cockpit. The poorly named allow_any tag controls the default policy for users logged in from any non-monitor+keyboard session. That is, sessions that don't come from a 'seat'. So unless your service is changing seat specific hardware, you probably want an allow_any tag that is similar or identical to allow_active. Erm, IMHO it should be the same as allow_inactive, if something is not allowed to be done from an inactive state (ie from a switched away session with fast user switching) it certainly should also not be allowed to be done over ssh. Technically you are correct. The best kind of correct. In reality it depends on the service. Some services may want to prevent use when inactive (ie: locked screen) simply for UI reasons, not security. This is not always the case though, as I have a package with a policy that I intentionally discriminate ssh from active sessions. Maybe it is better to decide that on a per-package case, and may be better to fill bugs to the specific packages that you think it doesn't make sense to have such discrimination. A longer-term solution may be to better explain the situation in the polkit documentation (if it isn't already - I didn't check). Otherwise with a blanket statement like the above we risk introducing security by-passes where we shouldn't. Security is never a case of always the case. So yes, if your package has special needs then by all means express that in the policy you distribute. Yes, polkit default policy is distributed per package, and customizable via rules from the sysadmin etc. Cheers, Stef -- 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: Fwd: F20 Self Contained Change: Shared Certificate Tools
On 12.07.2013 20:28, Toshio Kuratomi wrote: On Wed, Jul 10, 2013 at 01:22:37PM +0200, Jaroslav Reznik wrote: Because not all crypto implementations read their trusted information directly from the dynamic database, the tool will take care of extracting things as appropriate after making a change. This will enable administrators to run a single command to add an anchor (and perform other tasks). So it sounds like this is a modify and sync strategy? Are there other tools in the distribution that may modify the primary or the sync'd certificates that need to be changed so that they don't step on what p11-kit is doing? If I'm understanding you correctly, then we already have such a strategy. Admins modify files in /etc/pki/ca-trust and run update-ca-trust (is that the sync you're talking about) which makes sure all the legacy loaders of the certificates bundles get updated. This proposal simply adds a tool so that admins don't have to diddle files directly (although that is still supported). Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Manual page for Shared-System-Certificates feature
On 09.07.2013 15:30, Kai Engert wrote: A manual page is now available that describes the new Shared-System-Certificates feature. It's contained in this new build for F19: https://admin.fedoraproject.org/updates/ca-certificates-2012.87-10.4.fc19 (and in rahide, too). man update-ca-trust Please let us know if you have feedback. Please keep in mind that this documents things for Fedora 19. For Fedora 20 we aim to have simple tools to globally add and remove anchors and modify the blacklist. All the best, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 17.06.2013 13:22, David Woodhouse wrote: On Tue, 2013-06-11 at 07:47 +0200, Stef Walter wrote: even special locations for *particularly* braindamaged applications (pidgin). Hmmm, we should probably fix that one to use the central stuff. David, if we've missed any others in Fedora 19, could you file RHBZ bugs? I will, yes. I'm inferring that you *don't* need me to file a bug for pidgin because you're already looking at it? Is that (still) correct? Would be helpful to file a bug ... to make sure we're talking about the samething.. Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 17.06.2013 20:44, Przemek Klosowski wrote: On 06/05/2013 03:37 PM, Stef Walter wrote: What does work, and has been tested is logging in as root and simply typing this: realm join mydomain.com I filed https://bugzilla.redhat.com/show_bug.cgi?id=975182 because of confusing error messages when there is no pre-existing AD computer acct: Thanks for the bug. But I think this is a WONTFIX (or can't fix). Details in the bug. Please correct me if I've missed something. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 10.06.2013 23:35, David Woodhouse wrote: On Sun, 2013-06-09 at 09:24 +0930, Glen Turner wrote: I'd also strongly encourage a design which makes it easy for a corporate-issued RPM to configure the authentication. For an example of something wonderful, NetworkManager has a one-file-per-ssid design so its easy for a RPM to drop in the configuration files for the corporate wireless. I'd really like a company to be able to have a set of noarch RPMS which put in place the minimum configuration for use within the organisation. FWIW I've had some of this working fairly nicely. A firstboot module takes the user's AD credentials, uses the internal PKI infrastructure to obtain SSL certificates for wifi and VPN, drops the appropriate NetworkManager config into place. That's the easy bit. Also configuring Evolution-EWS and pidgin-sipe is a bit harder, and Evolution is even *harder* to configure like that now that its account config has been improved (I last had it working when it involved gconftool-2). And Fedora 19 should *finally* make it vaguely sane to import the corporate SSL CAs to a central location rather than having to do it in seventeen different places for different SSL libraries and sometimes Fedora 19 makes this possible (drop a file in a directory, run a command), and Fedora 20 will make in smooth (tools, apis for it). even special locations for *particularly* braindamaged applications (pidgin). Hmmm, we should probably fix that one to use the central stuff. David, if we've missed any others in Fedora 19, could you file RHBZ bugs? Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 04.06.2013 15:34, Simo Sorce wrote: On Tue, 2013-06-04 at 09:02 -0400, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2013 09:07 PM, Adam Williamson wrote: We all know what devel@ does best, so let's fire up the power of the bikeshedding machine :) We had https://bugzilla.redhat.com/show_bug.cgi?id=965883 on the list of release blocker candidates that we evaluated at the blocker review meeting this morning. Attendance at blocker reviews is pretty spotty these days (please, people, come out and feel in a position of ABSOLUTE POWER), and no-one present felt like they were a huge expert on typical remote authentication use cases, so we really didn't feel qualified to make a call on this one. As things stand, in Fedora 19, it's basically impossible to configure remote authentication from the install/firstboot process. If you want to use remote auth, you'd have to create a local user first and then do it using whatever tools are available. anaconda / initial-setup has a button for Use network login... on its 'user creation' spoke which ought to be where you configure remote auth, but right now it does precisely nothing at all. Whether this is a blocker or not comes down to a judgement call, because it hinges on whether this is a significant inconvenience for a large enough number of users. So we need to know from people who use Fedora in remote auth environments whether it's a big problem not to be able to set it up at install / firstboot time, or whether you'd be okay with creating a local user to get through initial-setup and then configuring remote auth from that local account. How did that happen? Last I had heard, Anaconda was supposed to be farming out to RealmD to do this. We should have no need to create a local user at all. CCing the RealmD maintainer for comment. Realmd is a good tool, but works only with Windows Ad or FreeIPA. It is useless to configure against a classic directory and/or Kerberos server or NIS or things like that. Agreed that is the case right now. But it's a goal to make it grow into those relevant use cases in that area so that we can have a non-Red-Hat-specific tool and API for accomplishing these things. On the other hand neither authconfig or realmd will ever provide all a GUI for the possible ways (many broken) ways you can possibly configure network authentication. Anaconda used to have authconfig integration, was it yanked on rewrite ? Anaconda did not have the GTK dialog. firstboot was the one that had it. And it's really broken for most use cases. It doesn't install necessary software or anything like that. So one really needs to know ahead of time all the dependencies of the network authentication you plan to use, and choose those in the installer. It was part of the plan to have a GUI for realmd be part of anaconda. But the merge of the basic anaconda kickstart patches, took so so long to merge (they've been ready since October) that the GUI bits were not done in time. See 'Contingency Plan' here: https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration#Contingency_Plan Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 05.06.2013 17:38, Simo Sorce wrote: On Wed, 2013-06-05 at 16:55 +0200, Stef Walter wrote: On 04.06.2013 15:34, Simo Sorce wrote: On Tue, 2013-06-04 at 09:02 -0400, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2013 09:07 PM, Adam Williamson wrote: We all know what devel@ does best, so let's fire up the power of the bikeshedding machine :) We had https://bugzilla.redhat.com/show_bug.cgi?id=965883 on the list of release blocker candidates that we evaluated at the blocker review meeting this morning. Attendance at blocker reviews is pretty spotty these days (please, people, come out and feel in a position of ABSOLUTE POWER), and no-one present felt like they were a huge expert on typical remote authentication use cases, so we really didn't feel qualified to make a call on this one. As things stand, in Fedora 19, it's basically impossible to configure remote authentication from the install/firstboot process. If you want to use remote auth, you'd have to create a local user first and then do it using whatever tools are available. anaconda / initial-setup has a button for Use network login... on its 'user creation' spoke which ought to be where you configure remote auth, but right now it does precisely nothing at all. Whether this is a blocker or not comes down to a judgement call, because it hinges on whether this is a significant inconvenience for a large enough number of users. So we need to know from people who use Fedora in remote auth environments whether it's a big problem not to be able to set it up at install / firstboot time, or whether you'd be okay with creating a local user to get through initial-setup and then configuring remote auth from that local account. How did that happen? Last I had heard, Anaconda was supposed to be farming out to RealmD to do this. We should have no need to create a local user at all. CCing the RealmD maintainer for comment. Realmd is a good tool, but works only with Windows Ad or FreeIPA. It is useless to configure against a classic directory and/or Kerberos server or NIS or things like that. Agreed that is the case right now. But it's a goal to make it grow into those relevant use cases in that area so that we can have a non-Red-Hat-specific tool and API for accomplishing these things. On the other hand neither authconfig or realmd will ever provide all a GUI for the possible ways (many broken) ways you can possibly configure network authentication. Anaconda used to have authconfig integration, was it yanked on rewrite ? Anaconda did not have the GTK dialog. firstboot was the one that had it. And it's really broken for most use cases. It doesn't install necessary software or anything like that. So one really needs to know ahead of time all the dependencies of the network authentication you plan to use, and choose those in the installer. It was part of the plan to have a GUI for realmd be part of anaconda. But the merge of the basic anaconda kickstart patches, took so so long to merge (they've been ready since October) that the GUI bits were not done in time. See 'Contingency Plan' here: https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration#Contingency_Plan So the endgame here is that there will be no remote authentication option in anaconda *nor* in firstboot. Is it really gone from firstboot? Can we get a button to skip g-i-s mandatory user creation then ? I think that makes sense for some Fedora use cases. It would mean skipping g-i-s all together, since it's heavily centered around setting up a user. In any case Matthias is the upstream maintainer and I think Fedora packager too. Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On 04.06.2013 17:44, Adam Williamson wrote:
On Tue, 2013-06-04 at 10:26 -0400, Przemek Klosowski wrote:
For what it's worth, remote authentication is increasingly important
where I sit, so everything that makes it easier to set up is welcome. As
of now, my cheat sheet for older Fedoras and RHEL is several pages long
and involves manual reconfiguration of samba/winbind, kerberos and pam
modules--but I haven't tried to do it in F19 yet, either way. What keeps
bugging me is that the whole lashup is fragile and involves magic
('winbind crashed with no error messages; restart it; oops crashed
again; restart samba maybe; YAY, success, don't touch anything')
I would be tickled pink if it's a more supported workflow now. I will
check it out and file bugs or kudos, depending on the outcome.
If you have issues, would love to hear about them. Please CC me on bugs.
If you're interested in getting involved, you can look through the test
cases here:
https://fedoraproject.org/wiki/Test_Day:2013-05-09_SSSD_Improvements_and_AD_Integration
Well, right now, you're not going to get any further than the cited bug
report (https://bugzilla.redhat.com/show_bug.cgi?id=965883 ) with
anaconda / i-s; that's all you get. g-i-s 0.11 should have
somewhat-working remote auth config support for the first time, though
as Simo has noted, it is more or less limited to AD and FreeIPA, and it
hasn't been tested very much at all (because up until 0.11 it was
utterly broken). Fedora 19 Final TC1 should be the first build with
g-i-s 0.11.
What does work, and has been tested is logging in as root and simply
typing this:
realm join mydomain.com
Alternatively put that command in kickstart.
Use --verbose to see gory details, and --user if necessary.
And then you should be able to use remote authentication and identities.
For now that's with FreeIPA and AD domains, but hopefully we'll be able
to do more later.
Cheers,
Stef
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Possible alternative behaviours for user creation at install time (was Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?)
On 22.05.2013 03:32, Simo Sorce wrote: Also I think realmd has no way to set pure LDAP accounts (RHDS, OpenLDAP, ...). Right, it doesn't yet have that ability. But realmd can gain the ability to configure other sources than the Active Directory and FreeIPA providers it currently supports. That said, it will always only support standard realms, not completely wild and woolly non-standard LDAP setups. For those you'll want to drop to the command line and configure manually. As you suggested on IRC, for OpenLDAP or RHDS we could support RFC 4876 [1] as a standard best-practice configuration that we could discover in realmd. Cheers, Stef [1] http://tools.ietf.org/html/rfc4876 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On 06.05.2013 21:51, Adam Williamson wrote: On Mon, 2013-05-06 at 21:37 +0200, Stef Walter wrote: On 06.05.2013 18:38, Adam Williamson wrote: On Mon, 2013-05-06 at 11:43 -0400, Rahul Sundaram wrote: On 05/06/2013 10:48 AM, Miloslav Trmač wrote: On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram wrote: On 05/04/2013 12:24 AM, Eric Sandeen wrote: On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no? On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it. Everything (certainly Anaconda and GNOME, not sure about KDE) is supposed to use libpwquality. Is that not so? They are definitely not enforcing the same rules. One obvious area of inconsistency is that some of the tools _warn_ on weak passwords, and some _block_ on weak passwords. We should standardize on one or the other of those. Not really. It makes complete sense to allow overriding the rules in certain contexts. For example when root is setting another user's password. But they have different behaviours for the same operation. For e.g., initial-setup and g-i-s have different behaviours for setting the password for the first user account. True. It's on my list of things to do to make AccountsService be able to use PAM to set the password, which then puts it through libpwquality. How that interacts with the password complexity requirements in g-i-s and g-c-c would need to be solved. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On 06.05.2013 18:38, Adam Williamson wrote: On Mon, 2013-05-06 at 11:43 -0400, Rahul Sundaram wrote: On 05/06/2013 10:48 AM, Miloslav Trmač wrote: On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram wrote: On 05/04/2013 12:24 AM, Eric Sandeen wrote: On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no? On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it. Everything (certainly Anaconda and GNOME, not sure about KDE) is supposed to use libpwquality. Is that not so? They are definitely not enforcing the same rules. One obvious area of inconsistency is that some of the tools _warn_ on weak passwords, and some _block_ on weak passwords. We should standardize on one or the other of those. Not really. It makes complete sense to allow overriding the rules in certain contexts. For example when root is setting another user's password. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On 04.05.2013 07:26, Michael Cronenworth wrote: On 05/03/2013 03:08 PM, Reartes Guillermo wrote: I think that the previous behaviour was better. (covering the password with bullets). At least the phones only show one character at a time, not the whole password. GTK shows everything or nothing with visibility being a boolean setting. GTK would need to gain the ability to do this most likely through a new property for a GtkEntry widget. There's already this exact phoneish password hint capability in GTK+ with the 'gtk-entry-password-hint-timeout' setting. Turn it on in $XDG_CONFIG_HOME/gtk-3.0/settings.ini, or use gtk_settings_set_string_property() Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mission Impossible #1: qt without gtk
On 30.04.2013 17:49, Eugene A. Pivnev wrote: 30.04.2013 19:26, David Howells: Eugene Pivnev ti.eug...@gmail.com wrote: 3. rpm -qa | grep gnome | xargs sudo yum remove * git (???) gitk, I imagine. David BTW - try to remove libgnome-keyring. I'm surprised: * PyQt4 * git * gvfs * kdelibs :-))) * phonon * qt-config Even though it's called libGNOME-keyring, libgnome-keyring isn't GNOME specific. But like Matthias said, porting to libsecret (which doesn't have the unfortunate name) is definitely the way forward. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: well!
On 03/12/2013 08:17 PM, Till Maas wrote: On Tue, Mar 12, 2013 at 12:47:07AM -0400, Digimer wrote: On 03/12/2013 12:41 AM, Charles Zeitler wrote: i don't like giving up control over my machine (partitioning), so i won't be upgrading to Fedora 18. i'll watch the web site for a return to sanity. charles zeitler Setting aside the drama, you can manually partition F18. Unless anaconda crashes (live image) or does not recognise the partitions (DVD image). :-/ Reference: https://bugzilla.redhat.com/show_bug.cgi?id=905669 Btw.: Ideas how to install F18 anyhow are welcome. If I'm honest, I couldn't get F18 Anaconda to install to the partition I wanted either :S I have multiple Linux OS partitions (Fedora 18, Rawhide, Ubuntu), and one big home directory partition, and I wanted Anaconda to replace one of them. Eventually I gave up, installed F18 to a VM, and then used rsync + restorecon + grub2-mkconfig (!) to get it into the partition I wanted. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On 02/14/2013 06:35 PM, Hans de Goede wrote: Hi, On 02/14/2013 01:28 PM, Bastien Nocera wrote: On Thu, 2013-02-14 at 10:53 +0100, Michael Schwendt wrote: On Thu, 14 Feb 2013 03:49:23 +0100, Kevin Kofler wrote: DJ Delorie wrote: Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors. So I suspect that Audacious started gnome-settings-daemon. It doesn't do that when I use OpenBox instead of GNOME, so OpenBox does not auto-spawn g-s-d. However, one of its plug-ins talks to DBus (org.gnome.SettingsDaemon) for GNOME media player keyboard shortcuts. That plug-in is enabled by default and by request, and anyone not running a compatible environment can easily switch it off in the preferences. Or you could fix the plugin to not auto-start the daemon so we don't get blamed for Audacious bugs... Actually after seeing this thread I was planning on sending a mail to ask people how to fix this. I guess that dbus-activation causes g-s-d to start when the audacious tries to talk to it. Rather then a less the friendly worded reply, it would be actually helpful if you could tell us (pointer to a code example would be a bonus) how to talk to a dbus interface without causing dbus-activation to trigger. Nothing fancy: http://developer.gnome.org/gio/unstable/GDBusConnection.html#GDBusCallFlags or http://dbus.freedesktop.org/doc/api/html/group__DBusMessage.html#ga1596d92a8d604f954b48c7410263d2f0 Obviously I can't list every single language or binding here. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 02/04/2013 06:28 AM, Kevin Kofler wrote: M. Edward (Ed) Borasky wrote: I love GNOME 3 and detest KDE 4. I've tried MATE and Cinnamon on both Linux Mint and Fedora and don't really see the point of either of them as long as GNOME 3 offers fallback mode. Fallback mode is going away in F19, it's already gone upstream. FWIW, see its replacement Classic Mode here: http://blogs.gnome.org/mclasen/2013/01/25/gnome-3-7-at-the-halfway-mark/ Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Less Brittle Kerberos
On 01/31/2013 07:57 PM, Ken Dreyer wrote: On Thu, Jan 31, 2013 at 4:47 AM, Jaroslav Reznik jrez...@redhat.com wrote: Kerberos clients can optionally verify reverse DNS records for services that they connect to as a way of trying to identify which realm they belong to. However in many cases these do not exist. Kerberos should fall back to it's default behavior in that case. Failure to do this is a common point of failure when using kerberos. Is this basically the same as what was discussed a while back on the MIT kerberos list?[1] If so, that is really great. It was not clear to me from the feature description if this will disable rdns entirely? Does this only covers cases where a PTR record is completely missing, or does it also cover cases where the PTR record present but incorrect (eg. doesn't match the forward record)? I have plenty of both situations at my site :-( That's not completely set in stone yet. Ideally we would change the default to match rdns = false. But if that's too invasive, we would make sure that the default does not fail when PTR records do not exist. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Less Brittle Kerberos
On 01/31/2013 10:35 PM, Kurt Seifried wrote: Can't reply on the wiki page, FAS is throwing a 500 server error when I try to log in. On Thu, Jan 31, 2013 at 4:47 AM, Jaroslav Reznik jrez...@redhat.com mailto:jrez...@redhat.com wrote: = Features/LessBrittleKerberos = https://fedoraproject.org/wiki/Features/LessBrittleKerberos Feature owner(s): Stef Walter st...@redhat.com mailto:st...@redhat.com Make kerberos in Fedora simpler to use by removing some of the brittleness that are common failure points. In particular we remove the need for kerberos clients to sync their clocks, and remove the need to have reverse DNS records carefully setup for services. == Detailed description == MIT kerberos 1.11 now contains work so that clients do not have to sync their system clocks with that of the KDC. A time offset is discovered during preauth and stored along with the local credentials. This removes a common point of failure when using kerberos. One concern, would this time offset be per server on the client, e.g. if people get used to this then a group of servers may all have varyingly wrong times (e.g. server A is 10 minutes fast, server B is 34 minutes slow and server C is only off by 2 seconds). It's stored per-realm on the client. But yes, things do definitely get more complicated when servers with out of sync times are involved. At this point, this feature is about kerberos clients being out of sync, not servers. This paper does outline some solutions for handling clock skew on servers, and eventually we'll want to make sure we can handle this in a robust and maintenance free way. http://static.usenix.org/publications/compsystems/1996/win_davis.pdf But for now, first step is to fix clock-skew for kerberos clients. This has real benefits for Fedora users and Also mitm attacks again. That's a very general statement so I'll ask for details. Have you found realistic MITM attack(s) in krb5 1.11? To be clear, the above paper was largely implemented a while back in MIT krb5, but only recently did we complete the work to make encrypted timestamp preauth work with clock skew. Is the following email post related to your concerns? If so, see the remainder of the discussion: http://mailman.mit.edu/pipermail/krbdev/2012-April/010769.html Kerberos clients can optionally verify reverse DNS records for services that they connect to as a way of trying to identify which realm they belong to. However in many cases these do not exist. Kerberos should fall back to it's default behavior in that case. Failure to do this is a common point of failure when using kerberos. would this for example cache data so that for example if the server has reverse DNS setup, then it stops woring the client warns the user (e.g. indicating a possible man in the middle attack)? I don't think so. Apparently many (most?) kerberos implementations do not look at reverse DNS data at all. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
On 01/30/2013 12:14 PM, Jóhann B. Guðmundsson wrote: On 01/30/2013 10:08 AM, Martin Sivak wrote: Hi, When I install a freeipa server I do not want firstboot because I am not going to create local users anyway. I am going to install freeipa and then create users in LDAP. Could such use cases not be built into firstboot? Right you are, see another proposed feature that works with FreeIPA and AD: https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration In rawhide I see that realmd is constantly running how can I turn it off? That's a bug. Could you file one in in RHBZ, and we can try and figure it out together? Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Shared System Certificates
On 01/25/2013 04:19 PM, Florian Weimer wrote: On 01/24/2013 12:30 PM, Stef Walter wrote: So yes, as noted in the 'Detailed Description' of the feature, long term we hope to follow this up with further work to make all the crypto libraries be able to process the information in its entirety. Okay. In the long term, it might make sense to offload the entire certificate chain validation to a daemon, so that it's possible to get consistent behavior across crypto libraries and allow system administrators to specify more detailed policies (but please not as Javascript code). Yeah, I agree with that in principle. In fact it's been tried before with libpkix. But in any case, doing this is a gargantuan task outside the scope of what we're taking on here right now. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Shared System Certificates
On 01/24/2013 09:12 AM, Florian Weimer wrote: On 01/23/2013 04:05 PM, Jaroslav Reznik wrote: OpenSSL: p11-kit tool will extract trusted certificate PEM blocks from the PKCS#11 trust module. These extracted certificates will be placed in a location so that they can be consumed by OpenSSL by default. The aim is that neither OpenSSL nor OpenSSL applications will have to be changed for this to work. I think OpenSSL (and GNUTLS, SunSSE) changes are unavoidable if we want to process the certdata.txt information in its entirety, including explicitly distributed intermediate certificates. Well we'll write out the appropriate OpenSSL 'trusted certificate' data so that it can consume that information. As far as GnuTLS and Java, yes, initially these will only be interacting with the CA certificate data information (and not other information like blacklists, and so on). So yes, as noted in the 'Detailed Description' of the feature, long term we hope to follow this up with further work to make all the crypto libraries be able to process the information in its entirety. This is just the first step for Fedora 19, but should solve many real world problems even though there is still future work to be done. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 users unable to log in due to cached nsswitch.conf
On 10/17/2012 07:02 PM, Simo Sorce wrote: This will take time however, in the meanwhile it would be really nice if we could do it the simple way by just adding sss by default until a better solution is found. I've posted a patch to do this at the bug: https://bugzilla.redhat.com/show_bug.cgi?id=867473 sssd-client is already installed by default in all but the minimal install. So with this one change things should work as appropriate. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F18 users unable to log in due to cached nsswitch.conf
In Fedora 17 and 18 we have a problem where remote users are unable to log in until the machine has been rebooted. This used to work previously. To fix this we probably need to: Include 'sss' in /etc/nsswitch.conf by default and have the small sssd-client package (with just thepam, nss plugins) installed on all but minimal Fedora installs. Is it too late to do this for Fedora 18? I'd jump in and provide the patches necessary. Sadly it's been hard to test a coherent system up until this point, so I thought this was a fluke of my test F18 systems until just the other day. Cheers, Stef DETAILS: This happens after configuration using authconfig to change /etc/nsswitch.conf (or doing it manually). The changes are not picked up by long running processes like dbus-daemon --system. As far as I can see dbus-daemon then refuses to allow connections from these users. As might be expected, gnome-shell crashes hard when this happens. There are some other ways to fix this problem, but these do not scale to fix the problem for every possible affected process: http://sourceware.org/bugzilla/show_bug.cgi?id=12459 Below I have a rough test for duplicating the problem. TEST CASE: * This should be ideally run on a freshly installed system or at least a system without sss in /etc/nsswitch.conf since last boot. $ grep sss /etc/nsswitch.conf ALREADY HAVE sss $ sudo -s # yum install sssd-tools pamtester # test -f /etc/sssd/sssd.conf mv /etc/sssd/sssd.conf /etc/sssd/sssd.conf.bak # echo -e [sssd]\ndomains=local\nconfig_file_version=2\nservices=nss,pam\n[domain/local]\nid_provider=local /etc/sssd/sssd.conf # chmod 0600 /etc/sssd/sssd.conf # systemctl start sssd.service # authconfig --update --enablesssd --enablesssdauth # sss_useradd --uid=2121 --gecos=Zapp zapp # passwd zapp # set password for zapp # pamtester zapp authenticate # type password, should succeed * Now go to gdm by logging out or switch user. * Try to log in as zapp. * Hang. * Reboot * Try to log in as zapp. * Success TRACKER BUG: https://bugzilla.redhat.com/show_bug.cgi?id=867473 Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 users unable to log in due to cached nsswitch.conf
On 10/17/2012 06:21 PM, Miloslav Trmač wrote: That's rather far from actually fixing the problem. Can we get it fixed_first_? It seems that we could drop the glibc caching, Obviously dropping the caching would be pretty nasty. Having to dlopen the modules each time you do a getpwnam() (or friends) isn't cool. I assume you mean fstating the file on each lookup? I'm not against this, and I can try and propose this to glibc, but I'm pretty sure what's going to happen. See similar /etc/resolv.conf discussions. or by modify authconfig to instruct the user to reboot after changing /etc/nsswitch.conf . That's *really* ugly, and prevents tools (like ipa-client-install or realmd) from completing an initialization in one shot. They would have to be split into two parts, with a reboot in between. :S I'm not opposed to changing the default nsswitch.conf to avoid that reboot (well, I think it's ugly to refer to a non-installed module, but that's an aesthetic, not a principal thing) and to improve the user experience in the default case, but we do need to have some way to fix the underlying problem, a better way than just giving up and conceding that nsswitch.conf can't be edited from now on. We are working on it and I linked to that bug in my report. Ray Strode and I are working on patches to glibc. http://sourceware.org/bugzilla/show_bug.cgi?id=12459 Obviously, if you have another idea of how to fix this other than the above, this would be a great place to put it forward. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up: Active Directory Integration test day
In case you're interested, there's an Active Directory integration test day for Fedora 18. Testing stuff like sssd and realmd with Active Directory. http://fedoraproject.org/wiki/Test_Day:2012-10-18_Active_Directory I'll be trying to get an Active Directory domain setup. But if you want to setup your own domain ahead of the test day (it's not that hard) then you can do so like this: http://stef.thewalter.net/2012/08/how-to-create-active-directory-domain.html See you there ;) Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
