[389-devel] 389 DS nightly 2018-06-23 - 65% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2018/06/23/report-389-ds-base-1.4.0.11-20180622gitd2c26d8.fc28.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/AIYCGKFLNNZ4IEOHY4Y5VOH2WWC5ZPQI/
Re: F29 System Wide Change: Make BootLoaderSpec the default
Once upon a time, Kyle Marek said: > On 06/22/2018 05:15 PM, Chris Adams wrote: > > And basic Unix permissions... because there can be privileged content in > > GRUB config and even initramfs. > > That's interesting. I generally don't see /boot as something that normal > users shouldn't be able to read. Or, in other words, I generally don't > see it as a place where secret data should be stored. > > Any particular examples? GRUB can have passwords to protect booting, menu options, and changing config. The initramfs can have network and iSCSI config for mounting the root filesystem. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PPY6WBGG5ORBQMTH25WEQGPFCHI7SDCM/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On 06/22/2018 05:15 PM, Chris Adams wrote: > Once upon a time, Matthew Miller said: >> On Fri, Jun 22, 2018 at 03:30:23PM -0400, Kyle Marek wrote: >>> Anaconda in F28 currently claims /boot cannot be vfat. However, this >>> appears to be an artificial limitation, because `grub2-install` works >>> and makes a bootable GRUB with a vfat-typed --boot-directory. >>> I'm not sure why there would be an issue with /boot being vfat. I guess >>> two good questions to ask that might offer some insight: >> Well, currently, we have things in there with different selinux >> labels > And basic Unix permissions... because there can be privileged content in > GRUB config and even initramfs. That's interesting. I generally don't see /boot as something that normal users shouldn't be able to read. Or, in other words, I generally don't see it as a place where secret data should be stored. Any particular examples? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/H2E27EMY6EMCZTYPKZVO5T7ZNVG3EO3S/
Re: F29 System Wide Change: Make BootLoaderSpec the default
Once upon a time, Matthew Miller said: > On Fri, Jun 22, 2018 at 03:30:23PM -0400, Kyle Marek wrote: > > Anaconda in F28 currently claims /boot cannot be vfat. However, this > > appears to be an artificial limitation, because `grub2-install` works > > and makes a bootable GRUB with a vfat-typed --boot-directory. > > I'm not sure why there would be an issue with /boot being vfat. I guess > > two good questions to ask that might offer some insight: > > Well, currently, we have things in there with different selinux > labels And basic Unix permissions... because there can be privileged content in GRUB config and even initramfs. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XDI3UNOKKWRUIH6GDQURD2XJKSHN6D4K/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Fri, Jun 22, 2018 at 1:54 PM, Kyle Marek wrote: > On 06/22/2018 03:35 PM, Chris Murphy wrote: > > What is the benefit to sharing $BOOT between different operating > systems/distros? Some of this is argued in the two BootLoaderSpecs. Mainly to avoid stomping on each other's installations and bootloaders, and a bit less redundancy instead of every distro having its own $BOOT. But really, how many people multiboot 2 or more Linux distros? My shits n giggles guess? Most common is Windows + Linux. Next most common macOS + Linux. Next most common Linux only. I think in some sense we're in the weeds on multibooting. It is possible we're overvaluing shared $BOOT. > I'd like to point out that $BOOT doesn't have to be shared to dual-boot > multiple distros or benefit from other details of BLS. True. Although the original BootLoaderSpec script file format only supports paths relative to $BOOT. There's no way to reference other volumes, even if they are readable by the firmware. You'd have to depend on the bootloader's native configuration file format instead of BLS format for such a feature, meaning no way to support it with one format across bootloaders. > Each installed OS that wants to use some derivative of BLS really *can* > just each have their own $BOOT and even use different bootloaders to > implement BLS. (bootloaders can be chained in BIOS, and they can exist > independently of each other in EFI) Sure. > The primary benefit I see to adopting BLS here is the drop-in > configuration and consistent syntax regardless of the implementing > bootloaders. The benefit to sharing $BOOT between operating systems > isn't obvious to me, and only introduces limitations such as this > filesystem one. I agree. And I like the consistent location and path. The change is a win, even if it's not a warm and fuzzy embrace of the whole BootLoaderSpec. It leaves the door open to either distros constraining their implementations toward BootLoaderSpec, or the broadening of the BootLoaderSpec to grow the market. My personal assessment is that the latter is more likely. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7WXRGNDMQ7VN73QUQN6TVRCW53VS73YJ/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Fri, Jun 22, 2018 at 1:30 PM, Kyle Marek wrote: > Anaconda in F28 currently claims /boot cannot be vfat. However, this appears > to be an artificial limitation, because `grub2-install` works and makes a > bootable GRUB with a vfat-typed --boot-directory. > I'm not sure why there would be an issue with /boot being vfat. I guess two > good questions to ask that might offer some insight: > > What filesystem limitations make vfat unappealing? (do we need symlinks?) Unappealing from a non-shared distro-centric point of view: no xattr, no POSIX permissions or owners, no links. Some of those things are unappealing and maybe disqualifying for a shared boot, security labels being one. So many things here are in possible conflict from the distro centric way of viewing the world, that simply have to change if we're really going to get to a shared $BOOT world. > Does Fedora plan to support installing with bootloaders other than GRUB on > x86? extlinux is an option supported by anaconda, it's not supported in that if something about it doesn't work we aren't going to block release; but it's a preferred bootloader for some VM images I think Cloud stuff was or is using extlinux. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z5GA5SWIMS2TH3FFBX2MS5WAY2GGUTDU/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Fri, Jun 22, 2018 at 12:57 PM, Lennart Poettering wrote: > On Fr, 22.06.18 19:01, Javier Martinez Canillas (jav...@dowhile0.org) wrote: > >> > Whereas constantly changing the ESP, means we need some way to >> > establish a master and rsync to the extras. >> >> So the consensus seems to be to have the BLS fragments in >> $BOOT/loader/entries even on EFI, where $BOOT is the boot partition >> mounted on /boot. That will give us the following advantages as >> mentioned in this thread: > > Uh, as one of the authors of the spec, I am not convinced using > arbitrary non-FAT file systems for $BOOT. In fact the spec currently > says it has to be VFAT. I wouldn't call that "consensus". Lennart, I sympathize, but face it. There is a single implementation of kernels and initramfs on the ESP and that's systemd-boot. Everyone else wants to get as far away from vfat as fast as possible. For a long time one of the first things a bootloader does is learn how to read a modern file system, including \EFI\Microsoft\Boot\bootmgfw.efi I totally get the arguments that GRUB is too big, too complicated, does too many things, each distro effectively live forks it into something often incompatible everywhere else. But systemd-boot really does go in the opposite extreme. I think it's too simple. But whatever. The spec's requirement that $BOOT be vfat was simply not going to go anywhere beyond systemd-boot and not even beyond UEFI. From that perspective, BootLoaderSpec as currently written is too UEFI centric and thus itself is not even trying to reach a consensus which is why it hasn't reached consensus. And systemd-boot could leverage other projects that wrap any of GRUB's existing file system modules as EFI programs to teach the firmware pre-boot environment how to read any file system you want, without having to write in separate support for file systems in systemd-boot. > Which file system do you have in mind even for this? Unspecified for now. i.e. no change. It would remain ext4 by default I expect, but ultimately whatever anaconda allows. > As far as I know it's very clear now that boot loaders have a hard > time implementing any of the current file systems properly. AFAIK the > XFS folks as one case were pretty clear that any implementation of XFS > which is not the in-kernel one is not supportable, but I am pretty > sure for the other more modern file systems things aren't too > different either. The fact that grub doesn't properly implement XFS is > a real issue, as I am sure you know, since it won't replay the > journal, and hence doesn't see changes made on previous boots when the > file system wasn't unmounted (which is a regularly seen issue, as ply > keeps XFS busy during shutdown), resulting in unbootable systems. This problem has many little saboteurs acting together to betray the user. It isn't really any one single thing, they all have to happen to capsize the ship. Nevertheless I pretty much find your original criticism that XFS sync() behavior is wrong, the most convincing. I'm happy to give all file systems a pass on fsync() dumping changes only to the log in such a way that only kernel log replay will catch things up properly. But in my sabotage testing, only XFS sync() behavior seems to end up with a file system that is unreliably readable by a bootloader. And I'm not a fan of non-atomic FIFREEZE/FITHAW as the work around, not least of which is I've found a way to sabotage it and break an updating system (with no estimate of how likely this is in the real world). > Why not just stick to VFAT? As mentioned, it's really the only thing > generally understood by everything that has a stake in boot > loading. Grub speaks it. The EFI firmware speaks it (and that also > means the EFI shell, which is immensly useful). Linux speaks it in the > initrd and after boot. Windows speaks it. MacOS speaks it. It's the > lowest common denominator and should be entirely sufficient to store a > few kernels and their initrds. I mean, we build our kernels as EFI > binaries on Fedora, IIRC. Wouldn't it be a pity if EFI can't actually > access them, because they are stored on an fs only Linux speaks? Wouldn't it be a pity if we didn't teach UEFI to read every goddamn file system ever invented just because we can?! http://efi.akeo.ie/downloads/efifs-latest/x64/ https://github.com/pbatard/efifs I mean honestly, we can teach EFI whatever the hell we want. File system support does not need to be baked into the bootloader on UEFI. Drop these guys onto your ESP and now the firmware with any bootloader can read any of those file systems directly. Pick one. I have to defer to others on the value of symlinks for atomic configuration swapout, but if you want the most widely supported file system that also has symlink support, it's UDF. For the time being though, the concept of a widely sharable $BOOT really doesn't have enough momentum or backing. I still think the change pushing us closer to BootLoaderSpec. But I also
Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
On Fri, Jun 22, 2018 at 07:24:54PM +0200, Björn Persson wrote: > Till Maas wrote: > > I do not see any reason why a user would put something in ~/bin that > > would mask something in /usr/bin except to actually mask the binary. It > > is the same with other user configuration, anyone expects ~/.ssh/config > > to override /etc/ssh/ssh_config instead of the other way round. > > It could happen by accident. A user might put a program in ~/bin that > happens to have the same name as one in /usr/bin that the user is > unaware of, and it might break other programs which call that command > without a full pathname. Editing ~/.ssh/config affects only SSH, and > isn't likely to break something unrelated. > > That's one reason why I'm not convinced that this change is a good > idea. It obviously has nothing to do with security though. It's a > matter of safety, which is different from security. In your opinion, how does the user act nowadays when something in /usr/bin masks their tool that they installed in ~/bin? I would assume that they will change the path, since installing the tool there is what they wanted. Making it hard for users to achieve their goals usually does not stop them. Also a tool with a same name in /usr/bin might also break another user's tool that expects the user version to be available in the PATH. I do not see how this would be better. And it might also happen with aliases or functions that users would configure in ~/.bashrc. I know that bash-completion using the _* namespace broke a lot of shortcuts that I used (and I still think it is sad that this easy to use prefix (at least on a QWERT* keyboard) was made unusable, even though these are identifiers nobody needs to type). Kind regards Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3JRVHYDX2HQ7NRIAZBLP54RMTYJQDQUV/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On 06/22/2018 03:35 PM, Chris Murphy wrote: > On Fri, Jun 22, 2018 at 11:01 AM, Javier Martinez Canillas > wrote: >> On Thu, Jun 21, 2018 at 11:19 PM, Chris Murphy >> wrote: >> >> [snip] >> > OK anyway, I don't see broad BLS consensus forming yet, but I do see > two items that aren't controversial and could move forward as part of > this feature proposal: > > a. Consistent $BOOT/loader/entries for UEFI and BIOS where $BOOT is > the ESP on UEFI, and $BOOT is "other" on BIOS (most likely the > existing /boot ext4 volume currently used). i.e. do not put > /loader/entries in /EFI/fedora By "consistent", do you mean that both EFI and BIOS boot loaders will reference the same entry files? I like that. >>> Yes. >>> However, I don't like the entries existing on ESP mostly because of the use case of md-RAID for /boot referenced in another thread. I think it would be best to just put the GRUB EFI file on ESP and put the rest of the bulk GRUB stuff in its utility partition (which may be RAID-ed). >>> Right. The config + kernel + initramfs on traditional /boot can make >>> use of software raid, depending on static one time proper >>> configuration of each member drive's ESPs and now the ESPs never need >>> to be touched and thus not sync'd. >>> >>> Whereas constantly changing the ESP, means we need some way to >>> establish a master and rsync to the extras. >>> >> So the consensus seems to be to have the BLS fragments in >> $BOOT/loader/entries even on EFI, where $BOOT is the boot partition >> mounted on /boot. That will give us the following advantages as >> mentioned in this thread: >> >> 1. The BLS will not be stored in vfat, so ostree could keep using >> symlinks to do atomic swap of its /boot/loader/entries >> 2. The ESP won't be modified on kernels install / removal, that will >> make it easier for software RAID. >> 3. There will be consistency on where the BLS fragments are installed >> regardless of the firmware interface (EFI, BIOS, OPAL on ppc64le and >> zipl on s390x will all use /boot/loader/entries). >> >> I've updated the wiki page to reflect this and we will also change the >> implementation. > > $BOOT being non-vfat is a fairly substantial departure from either > BootLoaderSpec, the original requires $BOOT be vfat, the mjg59 version > require $BOOT be firmware readable. That is not a complaint, I'm just > making an observation of the consequences. I'm personally on the fence > when it comes to the merit of a shared $BOOT. It sounds like a good > idea, but maybe it's specious? > > Just to give some people still hanging on to this thread a visual of > the dilemma: > > Not Shared $BOOT <||---> Shared $BOOT > md raid vfat > lvm, lvmraid udf > btrfsntfs > LUKS > F2FS > > By making it possible to put /boot/loader/entries on e.g. md or even > lvm raid1 or btrfs raid1, that implies a /boot/loader/entries that's > readable for very few bootloaders, and no operating systems other than > Linux. So it is not a shared $BOOT design. And that is a big departure > from the entire point of the BootLoaderSpec, which I think is a bit > too rigid. I think the spec would be better off presenting itself as > a continuum from a highly sharable $BOOT, to one that has features > that inevitably make it less sharable. > > e.g. Somewhere close to shared $BOOT would be udf or ntfs. Both have > read support on all major OS's, and by GRUB. Both support symlinks and > some other features of modern file systems that FAT lacks. But UDF > gets the edge on Linux because we have kernel level support, whereas > only FUSE support for NTFS. > > Syncing a share $BOOT without fancy Linux features (upper left list) > isn't that hard, it just requires a big dose of political capital to > get a service or daemon that most every distro is willing to support > in their core components so that sharing $BOOT doesn't result in out > of sync ESPs. That could be a supplement to BootLoaderSpec and > possibly a feature of systemd. But to date, there has been no one > willing to do that work. > > Anyway, I'm OK with all of the changes made so far. I think it does > simplify things quite a bit for Fedora users, while not shutting the > door on future standardization efforts. e.g. An option still available > to Fedora users is $BOOT on ESP where ESP automounts via systemd gpt > generator onto /boot - and you'll get /boot/loader/entries just like > everyone else if you want to use systemd-boot. What is the benefit to sharing $BOOT between different operating systems/distros? I'd like to point out that $BOOT doesn't have to be shared to dual-boot multiple distros or benefit from other details of BLS. Each installed OS that wants to use some derivative of BLS really *can* just each have their own $BOOT and even use different bootloaders to implement BLS. (bootloaders can be
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Fri, Jun 22, 2018 at 03:30:23PM -0400, Kyle Marek wrote: > Anaconda in F28 currently claims /boot cannot be vfat. However, this > appears to be an artificial limitation, because `grub2-install` works > and makes a bootable GRUB with a vfat-typed --boot-directory. > I'm not sure why there would be an issue with /boot being vfat. I guess > two good questions to ask that might offer some insight: Well, currently, we have things in there with different selinux labels -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ITW6XHUDUENH3WB6HKOJJS2R3YRJN7U3/
Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
On Fri, Jun 22, 2018 at 05:01:38PM +0100, Tomasz Kłoczko wrote: > On Fri, 22 Jun 2018 at 13:36, Till Maas wrote: > [..] > > > The attacker could have looked up the exploit on the web. > > > > If it is a public exploit, then it is usually fixed by updates, > > especially if the impact is that big. A user not installing > > security updates is a scenario I consider not worth to explore, since > > there might be all kinds of serious vulnerabilities. > > Just FTR. > If Fedora maintainers will decide to put ~/.local/bin over /usr/bin on > the $PATH it will be possible to control over ~/.local/bin/id (and/or > many more similar commands) what happens on begin of the user login > session. None of the packages updates (except that one which will > remove ~/.local/bin/ from the $PATH) would be able to stop damage ones > done. > > Would you consider now classify such change as serious vulnerability > introduction? No, the vulnerability is whatever allowed attackers to get write access to $HOME. And there would be a lot more changes to $HOME or other paths in a real-world attack that an update could not fix. Also I guess most attacks target information, computing power or network access and there is no way to revoke this with an update after the attack was successful. And the best practice to cleanup after an attack is to reinstall from known-good sources. Kind regards Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3FUF76JH5CTAGVXD4ZJWKCCAQNXOEEY5/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Fri, Jun 22, 2018 at 11:01 AM, Javier Martinez Canillas wrote: > On Thu, Jun 21, 2018 at 11:19 PM, Chris Murphy > wrote: > > [snip] > >>> OK anyway, I don't see broad BLS consensus forming yet, but I do see two items that aren't controversial and could move forward as part of this feature proposal: a. Consistent $BOOT/loader/entries for UEFI and BIOS where $BOOT is the ESP on UEFI, and $BOOT is "other" on BIOS (most likely the existing /boot ext4 volume currently used). i.e. do not put /loader/entries in /EFI/fedora >>> >>> By "consistent", do you mean that both EFI and BIOS boot loaders will >>> reference the same entry files? I like that. >> >> Yes. >> >>> However, I don't like the entries existing on ESP mostly because of the >>> use case of md-RAID for /boot referenced in another thread. I think it >>> would be best to just put the GRUB EFI file on ESP and put the rest of >>> the bulk GRUB stuff in its utility partition (which may be RAID-ed). >> >> Right. The config + kernel + initramfs on traditional /boot can make >> use of software raid, depending on static one time proper >> configuration of each member drive's ESPs and now the ESPs never need >> to be touched and thus not sync'd. >> >> Whereas constantly changing the ESP, means we need some way to >> establish a master and rsync to the extras. >> > > So the consensus seems to be to have the BLS fragments in > $BOOT/loader/entries even on EFI, where $BOOT is the boot partition > mounted on /boot. That will give us the following advantages as > mentioned in this thread: > > 1. The BLS will not be stored in vfat, so ostree could keep using > symlinks to do atomic swap of its /boot/loader/entries > 2. The ESP won't be modified on kernels install / removal, that will > make it easier for software RAID. > 3. There will be consistency on where the BLS fragments are installed > regardless of the firmware interface (EFI, BIOS, OPAL on ppc64le and > zipl on s390x will all use /boot/loader/entries). > > I've updated the wiki page to reflect this and we will also change the > implementation. $BOOT being non-vfat is a fairly substantial departure from either BootLoaderSpec, the original requires $BOOT be vfat, the mjg59 version require $BOOT be firmware readable. That is not a complaint, I'm just making an observation of the consequences. I'm personally on the fence when it comes to the merit of a shared $BOOT. It sounds like a good idea, but maybe it's specious? Just to give some people still hanging on to this thread a visual of the dilemma: Not Shared $BOOT <||---> Shared $BOOT md raid vfat lvm, lvmraid udf btrfsntfs LUKS F2FS By making it possible to put /boot/loader/entries on e.g. md or even lvm raid1 or btrfs raid1, that implies a /boot/loader/entries that's readable for very few bootloaders, and no operating systems other than Linux. So it is not a shared $BOOT design. And that is a big departure from the entire point of the BootLoaderSpec, which I think is a bit too rigid. I think the spec would be better off presenting itself as a continuum from a highly sharable $BOOT, to one that has features that inevitably make it less sharable. e.g. Somewhere close to shared $BOOT would be udf or ntfs. Both have read support on all major OS's, and by GRUB. Both support symlinks and some other features of modern file systems that FAT lacks. But UDF gets the edge on Linux because we have kernel level support, whereas only FUSE support for NTFS. Syncing a share $BOOT without fancy Linux features (upper left list) isn't that hard, it just requires a big dose of political capital to get a service or daemon that most every distro is willing to support in their core components so that sharing $BOOT doesn't result in out of sync ESPs. That could be a supplement to BootLoaderSpec and possibly a feature of systemd. But to date, there has been no one willing to do that work. Anyway, I'm OK with all of the changes made so far. I think it does simplify things quite a bit for Fedora users, while not shutting the door on future standardization efforts. e.g. An option still available to Fedora users is $BOOT on ESP where ESP automounts via systemd gpt generator onto /boot - and you'll get /boot/loader/entries just like everyone else if you want to use systemd-boot. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TKFDVPRTCL737REDIQ5TZN7AQH3ZXE3M/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On 06/22/2018 02:57 PM, Lennart Poettering wrote: > On Fr, 22.06.18 19:01, Javier Martinez Canillas (jav...@dowhile0.org) wrote: > >>> Whereas constantly changing the ESP, means we need some way to >>> establish a master and rsync to the extras. >> So the consensus seems to be to have the BLS fragments in >> $BOOT/loader/entries even on EFI, where $BOOT is the boot partition >> mounted on /boot. That will give us the following advantages as >> mentioned in this thread: > Uh, as one of the authors of the spec, I am not convinced using > arbitrary non-FAT file systems for $BOOT. In fact the spec currently > says it has to be VFAT. I wouldn't call that "consensus". > > Which file system do you have in mind even for this? > > As far as I know it's very clear now that boot loaders have a hard > time implementing any of the current file systems properly. AFAIK the > XFS folks as one case were pretty clear that any implementation of XFS > which is not the in-kernel one is not supportable, but I am pretty > sure for the other more modern file systems things aren't too > different either. The fact that grub doesn't properly implement XFS is > a real issue, as I am sure you know, since it won't replay the > journal, and hence doesn't see changes made on previous boots when the > file system wasn't unmounted (which is a regularly seen issue, as ply > keeps XFS busy during shutdown), resulting in unbootable systems. > > Why not just stick to VFAT? As mentioned, it's really the only thing > generally understood by everything that has a stake in boot > loading. Grub speaks it. The EFI firmware speaks it (and that also > means the EFI shell, which is immensly useful). Linux speaks it in the > initrd and after boot. Windows speaks it. MacOS speaks it. It's the > lowest common denominator and should be entirely sufficient to store a > few kernels and their initrds. I mean, we build our kernels as EFI > binaries on Fedora, IIRC. Wouldn't it be a pity if EFI can't actually > access them, because they are stored on an fs only Linux speaks? Anaconda in F28 currently claims /boot cannot be vfat. However, this appears to be an artificial limitation, because `grub2-install` works and makes a bootable GRUB with a vfat-typed --boot-directory. I'm not sure why there would be an issue with /boot being vfat. I guess two good questions to ask that might offer some insight: * What filesystem limitations make vfat unappealing? (do we need symlinks?) * Does Fedora plan to support installing with bootloaders other than GRUB on x86? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UW7ASBMC5VPEELQXZ5GTGC6ZZ3SNNRSX/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Fr, 22.06.18 19:01, Javier Martinez Canillas (jav...@dowhile0.org) wrote: > > Whereas constantly changing the ESP, means we need some way to > > establish a master and rsync to the extras. > > So the consensus seems to be to have the BLS fragments in > $BOOT/loader/entries even on EFI, where $BOOT is the boot partition > mounted on /boot. That will give us the following advantages as > mentioned in this thread: Uh, as one of the authors of the spec, I am not convinced using arbitrary non-FAT file systems for $BOOT. In fact the spec currently says it has to be VFAT. I wouldn't call that "consensus". Which file system do you have in mind even for this? As far as I know it's very clear now that boot loaders have a hard time implementing any of the current file systems properly. AFAIK the XFS folks as one case were pretty clear that any implementation of XFS which is not the in-kernel one is not supportable, but I am pretty sure for the other more modern file systems things aren't too different either. The fact that grub doesn't properly implement XFS is a real issue, as I am sure you know, since it won't replay the journal, and hence doesn't see changes made on previous boots when the file system wasn't unmounted (which is a regularly seen issue, as ply keeps XFS busy during shutdown), resulting in unbootable systems. Why not just stick to VFAT? As mentioned, it's really the only thing generally understood by everything that has a stake in boot loading. Grub speaks it. The EFI firmware speaks it (and that also means the EFI shell, which is immensly useful). Linux speaks it in the initrd and after boot. Windows speaks it. MacOS speaks it. It's the lowest common denominator and should be entirely sufficient to store a few kernels and their initrds. I mean, we build our kernels as EFI binaries on Fedora, IIRC. Wouldn't it be a pity if EFI can't actually access them, because they are stored on an fs only Linux speaks? Lennart -- Lennart Poettering, 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/C4EEYIG6HER4QTSPMLCMLESZYDGSHQLI/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Mon, Jun 18, 2018 at 02:42:40PM -0700, Andrew Lutomirski wrote: > > On Jun 18, 2018, at 10:02 AM, Javier Martinez Canillas > > wrote: > > > >> On Thu, Jun 14, 2018 at 10:20 PM, Chris Murphy > >> wrote: > >> On Thu, Jun 14, 2018 at 12:51 PM, Adam Williamson > >> wrote a monolithic config > > > > > > >> The cited BLS spec requires $BOOT be VFAT, are we doing that? > >> > > > > Yes for EFI systems but no otherwise. On EFI the BLS snippets are in > > /boot/efi/EFI/fedora/loader/entries and on non-EFI systems are in > > /boot/loader/entries. > > > > I think this is the wrong approach. I see no valid reason that the > paths should be different on EFI. Yeah, I think you've convinced Javier and I that we should just put the BLS fragments in /boot/loader/entries in either case. So that will probably happen next week sometime. > >> If there's no room on the EFI System partition for all of this, will > >> we following bullets 2 and 5 of the BLS spec under "The installer > > > > No, $BOOT is always the ESP where GRUB 2 is installed. > > I’m going to go out on a limb and make a stronger objection than > Chris’: I think that $BOOT SHOULD NOT be the ESP. The ESP is > problematic for any number of reasons. It’s usually vfat, so it’s > fragile. It does not support RAID safely. And it’s often small. > > Most of this can be solved by putting $BOOT on a different partition. > Stick it on mdadm 1.1 if you want RAID (*not* 1.0 or 0.9 due to > corruption risks [0]), and maybe even use a journaling filesystem that > the bootloader can *correctly* read. (That means the bootloader should > be able to parse the journal.). And make it however big you want. Yeah, I've never understood why some people seem to really want to use the ESP for anything that doesn't need to be read through the firmware's file I/O code. The only thing we really want to be loading from the ESP is the bootloader itself and some relatively static config data - basically, how to find /boot. For simplicity, I expect that means we'll make it be a grub.cfg that's generated once, and a grubenv file containing UUIDs and the like. Once we have most of this working well, I do intend on shipping an actual grub2-static-config package with a config file that isn't machine specific at all, but loads everything from bls, small config snippets (like grub-setpassword makes now), or grubenv, so you don't have to have grub-mkconfig or the other bulky tools installed at all on platforms that don't need grub-install. > As an extra plus, upgrading a kernel doesn’t require mounting the ESP, > which means that the bootloader installation can sync the ESP across > multiple disks and it will remain synced. Yeah, that's a thing you can do. > All that being said, $BOOT should not use security context xattrs — > getting that to work right across distros is probably impossible. Not to agree or disagree, but I'm not sure what of the above led you to say this part. > [0] I use mdadm a lot, and I never use 0.9 or 1.0. It’s too fragile. One caveat here (that's not particularly relevant to the broader conversation) is that you *can* make /boot and the ESP both reasonably redundant - obviously by using hardware RAID, but less obviously by using Intel's IMSM firmware RAID, because they made mdadm support it pretty well. But it's present on scarce few platforms in the world. -- Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SJYJ7LAK2CWOQEJYCT47EKXLKTOKZISI/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Mon, Jun 18, 2018 at 11:55:28PM +0100, Tom Hughes wrote: > On 18/06/18 23:46, Javier Martinez Canillas wrote: > > On Mon, Jun 18, 2018 at 11:54 PM, Tom Hughes wrote: > > > On 18/06/18 18:15, Peter Jones wrote: > > > > > > > That's true - though we actually shipped nearly all of the code to > > > > implement this stuff f28, minus some parts of the upgrade story and the > > > > anaconda bits to enable it by default. You can go run > > > > grub2-switch-to-blscfg today, and it will work. I hope :) > > > > > > > > > Unless you have /boot on your root partition like this machine > > > seems to have for some reason... Then it breaks because the loader > > > fragments use /vmlinuz... rather than /boot/vmlinuz etc. > > > > > > > Yes, /boot not being a mount point was an issue (and also /boot being > > a btrfs subvolme) but it got fixed [0] a couple of weeks ago. Now the > > 20-grub.install kernel-install script uses grub2-mkrelpath to get the > > relative path of the kernel and initramfs images, which is the same > > that's done by the /etc/grub.d/10_linux script. It's just that the > > grub2 update didn't made to F28 yet. > > Does that extend to grub2-switch-to-blscfg as well? That was what > broke my boot. Yes, I've already got that fixed in my git repo, and it'll be fixed to do that when I do the next f28 update. -- Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QESTGIFYYKKBHCBSVYZ4EURLVIO4QTZH/
Re: Heads up: Python 3.7 rebuild in progress
On Wed, 13 Jun 2018, 14:14 Miro Hrončok, wrote: > I've just started to build the bootstrap sequence in a side tag > (f29-python). > > This should not affect you mostly but if you have a Python 3 package and > you are going to update it with new buildtime dependencies, please let > me know or wait until this is done. > > The initial order is in > https://github.com/hroncok/rpm-list-builder/blob/python37/python37.yaml Last night I updated python-lz4 to a new upstream release. That adds a dependency on python-psutil. > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YIDXSEJLCGEPBZ4UASBX7LQAKLMFLFKK/
Re: i686 kernel missing on rawhide / disabling archs in critical path pkgs
On 06/22/2018 08:37 AM, Jerry James wrote: On Thu, Jun 21, 2018 at 2:50 AM Daniel P. Berrangé wrote: Fedora rawhide has not had any kernel build available for i686 for a week now. It was disabled in a rebase due to part of the build process segfaulting. The bug causing the segfault is not specific to i386. It could happen on any architecture. There is an incorrect loop termination condition that can lead to an array index wrapping around to (size_t)-1. Try the attached patch. It fixes the issue for me. (I tried to mimic a git-produced patch without actually having a git checkout of the kernel handy. If somebody wants to generate that patch the right way and submit it upstream, that would be great.) Thanks for the patch. Once someone verifies this fixes the i686 problem and makes an attempt to submit it upstream I will see about applying it to the tree. Thanks, Laura ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QPB7YXFCXBEH2ZFVGK52G5UQB63NJYLC/
Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
Till Maas wrote: > I do not see any reason why a user would put something in ~/bin that > would mask something in /usr/bin except to actually mask the binary. It > is the same with other user configuration, anyone expects ~/.ssh/config > to override /etc/ssh/ssh_config instead of the other way round. It could happen by accident. A user might put a program in ~/bin that happens to have the same name as one in /usr/bin that the user is unaware of, and it might break other programs which call that command without a full pathname. Editing ~/.ssh/config affects only SSH, and isn't likely to break something unrelated. That's one reason why I'm not convinced that this change is a good idea. It obviously has nothing to do with security though. It's a matter of safety, which is different from security. Björn Persson pgpNNmJlUq98I.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6HNKT2634Y4VWC52KYTEMFWPJST6ETAY/
Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
Tomasz Kłoczko wrote: > Just FTR. > If Fedora maintainers will decide to put ~/.local/bin over /usr/bin on > the $PATH it will be possible to control over ~/.local/bin/id (and/or > many more similar commands) what happens on begin of the user login > session. None of the packages updates (except that one which will > remove ~/.local/bin/ from the $PATH) would be able to stop damage ones > done. > > Would you consider now classify such change as serious vulnerability > introduction? If you state a falsehood again and again it will eventually become true? Björn Persson pgpRkTK3_EirR.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/T5KBVFSRR46O6W5SEI3GU4GGOOINBDQR/
Re: [Fedora-packaging] DRAFT: Change to Systemd Packaging Guidelines - Was Re: Services that shouldn't be started in the first place
FESCo has decided to review this topic at their next meeting. I will hold off submitting another draft pending the results of that discussion. https://pagure.io/fesco/issue/1918 On Thu, Jun 21, 2018 at 5:05 PM, Gerald B. Cox wrote: > > > On Thu, Jun 21, 2018 at 3:14 PM, Jason L Tibbitts III > wrote: > >> > "GBC" == Gerald B Cox writes: >> >> To me this doesn't make much sense in the context in which you have put >> it. The existing hardware activation section is just this paragraph: >> ... >> I don't disagree with the idea behind what you're proposing, but the >> hardware activation section is quite the wrong place to put it. >> >> It seems to me that a far more appropriate place would be in the >> https://fedoraproject.org/wiki/Packaging:DefaultServices document >> > ... > > Completely agree. I'll make the changes and repost another draft via > email. > > Thanks for you help Jason! > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FSLESRYUIDP73SUSW5RNAMOW2NM5P74B/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Thu, Jun 21, 2018 at 11:19 PM, Chris Murphy wrote: [snip] >> >>> OK anyway, I don't see broad BLS consensus forming yet, but I do see >>> two items that aren't controversial and could move forward as part of >>> this feature proposal: >>> >>> a. Consistent $BOOT/loader/entries for UEFI and BIOS where $BOOT is >>> the ESP on UEFI, and $BOOT is "other" on BIOS (most likely the >>> existing /boot ext4 volume currently used). i.e. do not put >>> /loader/entries in /EFI/fedora >> >> By "consistent", do you mean that both EFI and BIOS boot loaders will >> reference the same entry files? I like that. > > Yes. > >> However, I don't like the entries existing on ESP mostly because of the >> use case of md-RAID for /boot referenced in another thread. I think it >> would be best to just put the GRUB EFI file on ESP and put the rest of >> the bulk GRUB stuff in its utility partition (which may be RAID-ed). > > Right. The config + kernel + initramfs on traditional /boot can make > use of software raid, depending on static one time proper > configuration of each member drive's ESPs and now the ESPs never need > to be touched and thus not sync'd. > > Whereas constantly changing the ESP, means we need some way to > establish a master and rsync to the extras. > So the consensus seems to be to have the BLS fragments in $BOOT/loader/entries even on EFI, where $BOOT is the boot partition mounted on /boot. That will give us the following advantages as mentioned in this thread: 1. The BLS will not be stored in vfat, so ostree could keep using symlinks to do atomic swap of its /boot/loader/entries 2. The ESP won't be modified on kernels install / removal, that will make it easier for software RAID. 3. There will be consistency on where the BLS fragments are installed regardless of the firmware interface (EFI, BIOS, OPAL on ppc64le and zipl on s390x will all use /boot/loader/entries). I've updated the wiki page to reflect this and we will also change the implementation. Best regards, Javier ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B3SMCSWFFEYIJIWPESY27MB6AMH3DH52/
Re: i686 kernel missing on rawhide / disabling archs in critical path pkgs
On Fri, 22 Jun 2018 09:37:15 -0600 Jerry James wrote: > On Thu, Jun 21, 2018 at 2:50 AM Daniel P. Berrangé > wrote: > > Fedora rawhide has not had any kernel build available for i686 for a > > week now. It was disabled in a rebase due to part of the build > > process segfaulting. > > The bug causing the segfault is not specific to i386. It could happen > on any architecture. There is an incorrect loop termination condition > that can lead to an array index wrapping around to (size_t)-1. Try > the attached patch. It fixes the issue for me. (I tried to mimic a > git-produced patch without actually having a git checkout of the > kernel handy. If somebody wants to generate that patch the right way > and submit it upstream, that would be great.) Doesn't that error (nread wrapping) imply that the file being read is empty, except for some trailing newlines? I think your fix is just a workaround for a bad input file. It's great to deal with a corner case, but wouldn't the issue be why the file being read is empty except for trailing newlines (when it isn't on any other arch). I don't understand the purpose of the routine, but the name cmd implies the file is supposed to contain a command of some sort. It would also work if it was completely empty (no trailing new lines). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7XFLPGFX3ARVC7DOAGA6JIWQF2JSTD3G/
Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
On Fri, Jun 22, 2018 at 05:01:38PM +0100, Tomasz Kłoczko wrote: > If Fedora maintainers will decide to put ~/.local/bin over /usr/bin on > the $PATH it will be possible to control over ~/.local/bin/id (and/or > many more similar commands) what happens on begin of the user login > session. None of the packages updates (except that one which will > remove ~/.local/bin/ from the $PATH) would be able to stop damage ones > done. It does seem like /etc/profile and others should be updated to use full paths for these commands. I don't think this particularly expands the attack surface in any meaningful way, though. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BBJIOFDG7JYD2B53HJYAMHW446HZJS7N/
Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
On Fri, 22 Jun 2018 at 13:52, Till Maas wrote: [..] > No, it does not change everything as attackers can also just copy > desktop files with other Exec-Keys to > > /home/till/.local/share/applications, for example like this: > > sed -e s,Exec=.*,Exec=xmessage\ pwned, > /usr/share/applications/firefox.desktop > > ~/.local/share/applications/firefox.desktop > > There is no need to drop something in the path to manipulate desktop > files/the applications that are started (I verified this with Gnome on > Fedora 28). Please stop with these false claims. Yep, It is known. Few people have been trying to convince other people to ignore any Exec lines in ~/.local/share/applications/*desktop files to allow icons or menu entries texts changes still possible or at least make this as the desktop settings option. So far no success. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2O2GXACHISCCAFXXCMWZ4G4G6H637LVS/
Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
On Fri, 22 Jun 2018 at 13:36, Till Maas wrote: [..] > > The attacker could have looked up the exploit on the web. > > If it is a public exploit, then it is usually fixed by updates, > especially if the impact is that big. A user not installing > security updates is a scenario I consider not worth to explore, since > there might be all kinds of serious vulnerabilities. Just FTR. If Fedora maintainers will decide to put ~/.local/bin over /usr/bin on the $PATH it will be possible to control over ~/.local/bin/id (and/or many more similar commands) what happens on begin of the user login session. None of the packages updates (except that one which will remove ~/.local/bin/ from the $PATH) would be able to stop damage ones done. Would you consider now classify such change as serious vulnerability introduction? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XMA24FNN3KHBUPNQAGWDGYVRJ32Z4LE4/
[Bug 1594050] perl-Test-POE-Client-TCP-1.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1594050 --- Comment #5 from Fedora Update System --- perl-Test-POE-Client-TCP-1.16-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-7aba6547fd -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/M3D7A5ECBJPMRVE7CMXU7ZMICFTOBY2G/
Re: i686 kernel missing on rawhide / disabling archs in critical path pkgs
On Thu, Jun 21, 2018 at 2:50 AM Daniel P. Berrangé wrote: > Fedora rawhide has not had any kernel build available for i686 for a > week now. It was disabled in a rebase due to part of the build process > segfaulting. The bug causing the segfault is not specific to i386. It could happen on any architecture. There is an incorrect loop termination condition that can lead to an array index wrapping around to (size_t)-1. Try the attached patch. It fixes the issue for me. (I tried to mimic a git-produced patch without actually having a git checkout of the kernel handy. If somebody wants to generate that patch the right way and submit it upstream, that would be great.) Regards, -- Jerry James http://www.jamezone.org/ From: Jerry James Date: Fri, 22 Jun 2018 09:28:15 -060 Subject: [PATCH] kconfig: loop boundary condition fix If buf[-1] just happens to hold the byte 0x0A, then nread can wrap around to (size_t)-1, leading to invalid memory accesses. --- a/scripts/kconfig/preprocess.c.orig 2018-06-22 08:36:01.601896556 -0600 +++ b/scripts/kconfig/preprocess.c 2018-06-22 09:19:03.745447415 -0600 @@ -156,7 +156,7 @@ static char *do_shell(int argc, char *ar nread--; /* remove trailing new lines */ - while (buf[nread - 1] == '\n') + while (nread > 0 && buf[nread - 1] == '\n') nread--; buf[nread] = 0; ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NBLLSNXQLTLQE5BL4FQQMPTB5W4YXA3B/
Re: i686 kernel missing on rawhide / disabling archs in critical path pkgs
On 22 June 2018 at 05:29, Daniel P. Berrangé wrote: >> I encourage you to file a ticket with FESCO. > > I was hoping this mail would generate some more discussion perhaps with > other ideas than I've come up with. > > If there's continued silence and i686 kernel doesn't get fixed soon, > I'll file ticket with FESCO asking for i686 arch to be removed from > main koji and relegated to a secondary koji instance, so i686 doesn't > block maintainers going forward... > There is no secondary koji, and releng has said in the past they don't want to go back to dealing with it. Dropping i686 is dropping i686 completely for both lib and multilib. The same will be with any other architecture which causes such blockages in the future. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QNHYOMJJZSGL6EJNLK25PYPRJ5ZRM6KO/
Re: i686 kernel missing on rawhide / disabling archs in critical path pkgs
On Fri, 22 Jun 2018 08:55:16 -0500 Justin Forbes wrote: > On Fri, Jun 22, 2018 at 8:49 AM, Rex Dieter > wrote: > > Daniel P. Berrangé wrote: > > > >> If there's continued silence and i686 kernel doesn't get fixed > >> soon, I'll file ticket with FESCO asking for i686 arch to be > >> removed from main koji and relegated to a secondary koji instance, > >> so i686 doesn't block maintainers going forward... > > > > Not sure it's as simply as that. Doing as you suggest means > > multilib support is lost too. > > > > Right, the proper solution would be officially dropping the i686 > kernel, and leaving just the headers package. That would mean that > packages which also depend on the actual kernel itself would be > modified to drop i686 builds. In such a case, if the SIG were to > decide to continue trying for an i686 release, those packages > themselves would need to be built on a secondary koji, though they > could still use the packages that are build in primary for multilib. we handled 32-bit s390 multilib under s390x similarly, no kernel, but all userspace was built Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/X35UBTEVCTA3SUH4LAHT3ZU3ZKWD2QDA/
Re: i686 kernel missing on rawhide / disabling archs in critical path pkgs
On Fri, Jun 22, 2018 at 08:49:04AM -0500, Rex Dieter wrote: > Daniel P. Berrangé wrote: > > > If there's continued silence and i686 kernel doesn't get fixed soon, > > I'll file ticket with FESCO asking for i686 arch to be removed from > > main koji and relegated to a secondary koji instance, so i686 doesn't > > block maintainers going forward... > > Not sure it's as simply as that. Doing as you suggest means multilib > support is lost too. Oh true, I guess then I'll just disable building on i686 for various features and/or entire packages Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XZFNKAC3WVJZMWKNTJKS53TQJQMPXGO2/
Re: i686 kernel missing on rawhide / disabling archs in critical path pkgs
On Fri, Jun 22, 2018 at 8:49 AM, Rex Dieter wrote: > Daniel P. Berrangé wrote: > >> If there's continued silence and i686 kernel doesn't get fixed soon, >> I'll file ticket with FESCO asking for i686 arch to be removed from >> main koji and relegated to a secondary koji instance, so i686 doesn't >> block maintainers going forward... > > Not sure it's as simply as that. Doing as you suggest means multilib > support is lost too. > Right, the proper solution would be officially dropping the i686 kernel, and leaving just the headers package. That would mean that packages which also depend on the actual kernel itself would be modified to drop i686 builds. In such a case, if the SIG were to decide to continue trying for an i686 release, those packages themselves would need to be built on a secondary koji, though they could still use the packages that are build in primary for multilib. Justin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JZ3YEQ562X237JRSFDFS4QGIJWSXKUMH/
Re: i686 kernel missing on rawhide / disabling archs in critical path pkgs
Daniel P. Berrangé wrote: > If there's continued silence and i686 kernel doesn't get fixed soon, > I'll file ticket with FESCO asking for i686 arch to be removed from > main koji and relegated to a secondary koji instance, so i686 doesn't > block maintainers going forward... Not sure it's as simply as that. Doing as you suggest means multilib support is lost too. -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JSIC2KIBXURGODOXOO23OA4K7G3REWZV/
[Bug 1594050] perl-Test-POE-Client-TCP-1.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1594050 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- perl-Test-POE-Client-TCP-1.16-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c4131d0e36 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/UPTNNJ3IDIDQAM6JZBKMLX2G5J462PLS/
Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
On Mon, Jun 18, 2018 at 02:17:43PM +0100, Tomasz Kłoczko wrote: > For example in case of have /usr/local/bin/id you can observe that > gnome-terminal started from command line and GUI menu are altere. > In other words this effect is literally spreads as well across most of > the /usr/share/application/*desktop files (just grep those files for > ^Exec=). > Using in Exec= only binary name instead full path would be nothing bad > .. however this mixed with currently used $PATH really changes > everything! No, it does not change everything as attackers can also just copy desktop files with other Exec-Keys to /home/till/.local/share/applications, for example like this: sed -e s,Exec=.*,Exec=xmessage\ pwned, /usr/share/applications/firefox.desktop > ~/.local/share/applications/firefox.desktop There is no need to drop something in the path to manipulate desktop files/the applications that are started (I verified this with Gnome on Fedora 28). Please stop with these false claims. Kind regards Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4IT3C2JTRLTNI74UJYWXMTPY5QZNOZJT/
Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
On Sat, Jun 16, 2018 at 01:17:57PM -0400, Nico Kadel-Garcia wrote: > * Stolen passwords from penetrated hosts, used for SSH connections. > Copying a file to $HOME/.local/bin requires far less scripting and > awareness of existing contents than editing of .bashrc or .profile > that reveals timestamp changes of the edited file, and differs from > system defaults. Since the contents of $HOME/.local/bin are not > defined or definable, by its very nature, it's harder to audit. The system default would be that they are empty or contain the files that are put there by default. Not really harder to audit that a .bashrc file. Also if you can use SSH to access the system, you can just execute commands. If you can only copy files, why is copying content to ~/.i18n less bad? > * Fileshares of home directories. Many environments, especially > university environments, use NFSv3 with quite general access. Welcome > to write access to $HOME/ !!! And $HOME/.local/bin is notably less > apparent than $HOME/bin, due to the default lack of "ls" reporting of > contents of "." prefaced directories, and of the difficulty of leaving > security auditing to check .bashrc, .profile, etc. Still, why would an attacker then copy something to these directories instead of to ~/.i18n, or ~/.ssh/config or ~/.vimrc? Also if you want to do a proper audit of all executables in the PATH the first step would be to check the value of $PATH because this is something an attacker could also change to any other value that would need to be checked. And once you look at $PATH, ~/.local/bin is no longer hidden because it is in plain sight there, even easier to spot when it is at the beginning. > Does that give you enough examples of unnecessarily vulnerable vectors > opened by default by the casual assumption that "ohh, they could get > in another way, so I don't have to worry about the hole *I* am > suggesting opening up!!!" No, in your examples $HOME would be compromised anyhow already. Kind regards Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6ADYSLRDQ72VOPLMPMCN26ZSOJUBIWCV/
Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
On Fri, Jun 15, 2018 at 06:56:16PM +0200, Alois Mahdal wrote: > > > On 06/15/2018 11:24 AM, Till Maas wrote: > > ...] > > > >> What I'm trying to say is that with these kinds of attack (like viruses, > >> or exploits on massively accessed page), there is inevitably going to be > >> some sort of economic decision on side of author affecting how "smart" > >> they want the code to be. > >> > >> Thus, every little step you're making towards "easier" translates to > >> dumber exploits being able to succeed. Suddenly not just those that did > >> 2 things but also those that did 1 thing. > > > > So the assumption is to have a super sophisticated browser exploit for > > which an attacker most likely spent several days to find it and then the > > PATH setting will make it so much harder that the exploit will not > > succeed? There are a lot more real challenges that attackers have to face. > > The attacker could have looked up the exploit on the web. If it is a public exploit, then it is usually fixed by updates, especially if the impact is that big. A user not installing security updates is a scenario I consider not worth to explore, since there might be all kinds of serious vulnerabilities. > I think you keep putting some kind of base standard on the hypothetical > attacker and then your argument is "if they can do X then they can do > Y". Because we're both SW engineers, the relation between X and Y is > obvious to us, so yeah, anybody who would do X would totally obviously > also do Y. Sure, we've been there so many times we don't even think > about it. This is a useful way to categorize security vulnerabilities because they should allow an attacker to gain more privileges/possibilities/... And if we assume that a system is secure because people do not know about other possibilities, then it is security by obscurity which does not work in practice. > OTOH, I don't think that's the best way to think about security. There > are no standards. The amount of code (dedicated to Linux) could > totally be just that single line, writing the payload to .local/bin. > By including the path in default $PATH, you are allowing also the > on-bit-dumber attack to succeed (... now with all Fedora users, yay!...) Is this realistic? There a endless other possibilities and there is no reason why an attack to access exactly these directory paths is more likely than the many other possibilities. Also why would attackers choose this path in the first place? Putting a new ~/.i18n file in the user's home directory seems to me to be more likely to succeed. > I'm saying there is some impact. I'm not aware of any meaningful way to > measure it, but I don't think it's necessary: IMHO even making a "minor" > impact is already bad idea. I do not agree because the way you argue could be applied to anything and there could always be the one imaginary exploit that will have a payload that will only work because of $whatever and therefore make in impact. For example from the other changes, what if there is a payload that uses a feature of Golang 1.11 or a bug that is fixed in Binutils 2.31. > Especially if I don't really see any convincing reason why this should > be done. I do not see any reason why a user would put something in ~/bin that would mask something in /usr/bin except to actually mask the binary. It is the same with other user configuration, anyone expects ~/.ssh/config to override /etc/ssh/ssh_config instead of the other way round. Kind regards Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Q6NQNBDAXGDD5RX2RKX6HRUHJRXU6I4P/
[Bug 1594219] New: ack-2.24 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1594219 Bug ID: 1594219 Summary: ack-2.24 is available Product: Fedora Version: rawhide Component: ack Keywords: FutureFeature, Triaged Assignee: robinlee.s...@gmail.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, robinlee.s...@gmail.com Latest upstream release: 2.24 Current version/release in rawhide: 2.22-2.fc28 URL: http://search.cpan.org/dist/ack/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/15/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/KW2SD765XKOWCGHD2ZGZAZEZAUYMPXJL/
Re: F29 System Wide Change: Binutils 2.31
On Mon, Jun 18, 2018 at 09:12:35AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jun 14, 2018 at 05:16:31PM +0200, Jan Kurik wrote: > > The linker can now put all code and read-only data sections into a > > separate segment with only READ and EXECUTE permissions. All writable > > data can be placed into a separate segment with READ and WRITE > > permissions. This makes programs larger, but safer. The linker's > > behaviour can be controlled via a command line option, and the default > > set by a configure option. > Will this configuration option be switched on in Fedora? > > > Switch the binutils package from being based on the 2.30 release of > > the FSF binutils to being based on the 2.31 release. This release > > will bring in numerous bug fixes, as well as the following new > > features: > Do you foresee any significant issues with this version upgrade in the > mass rebuild? Anything in particular that maintainers and upstreams > should looks at? > > Zbyszek Also, what is the relationship between https://fedoraproject.org/wiki/Changes/BINUTILS230 and https://fedoraproject.org/wiki/Changes/BINUTILS231 ? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FGC562V5UVCJTW6UHED4IKBPTQAPOABQ/
Re: i686 kernel missing on rawhide / disabling archs in critical path pkgs
On Thu, Jun 21, 2018 at 07:36:30AM -0700, Laura Abbott wrote: > On 06/21/2018 01:50 AM, Daniel P. Berrangé wrote: > > The kernel change that introduced the i686 build problem was just a > > rebase between 2 arbitrary pre-release git snapshots. I don't really > > a compelling justification to rebase to a known broken snapshot, > > without allowing time for x86 SIG to resolve it first. AFAIK there > > was no prior warning or request for help - i686 was just disabled > > immediately and other package maintainers left to deal with the > > consequences of broken deps. > > > A more pragmatic approach would have been to report the problem to the > > x86 SIG and then *not* do the rebase for some reasonable period of time > > (perhaps 1 week grace period), to allow for the problem to be addressed. > > Only disable the i686 build if there is no solution is forthcoming, thus > > avoiding causing this pain for a whole chain of packages/maintainers in > > Fedora. > > > > > > I'll admit to not realizing just how many problems disabling this > would cause so I do apologize for that. This came in during the > merge window when we really want to be getting things out to test > so it seemed worth it to just disable it and move on. > > > Having said all this, the message about brokenness on x86 SIG mailing > > list doesn't appear to be treated with the urgency I think it needs, > > givin the ripple effect it has from a critical path package. There were > > a few messages the day after it was reported, and then nothing until > > Wednesday. > > > > The silence on the mailing list is an example of why I didn't try > asking first before rebasing. I know there are a few people who are > very passionate about i686 but the fact of the matter is the response > rate for actual problems has been very low. If someone had responded > with "this will be fixed by date X" I would have been willing to > revert and wait but that's a big part of the issue: nobody is driving > or setting direction. If someone had even told me "Talk to person X > instead of just the mailing list" I would have done that as well. > > Thorsten Leemhuis also pointed out this problem has been going > on for a while https://bugzilla.redhat.com/show_bug.cgi?id=1592374#c1 > > > > For a package that is critical path like the kernel, I'd expect this > > to be a top priority item to resolve with immediate effect because of > > the broad impact it has on other maintainers. Maybe this has been > > happening in the background, with no activity visible on the mailing > > list, if so I apologize in advance. > > > > I encourage you to file a ticket with FESCO. I was hoping this mail would generate some more discussion perhaps with other ideas than I've come up with. If there's continued silence and i686 kernel doesn't get fixed soon, I'll file ticket with FESCO asking for i686 arch to be removed from main koji and relegated to a secondary koji instance, so i686 doesn't block maintainers going forward... Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QVHZLD57W7TKKN2CZOSDXQATQPBL2MQC/
[Bug 1594041] perl-File-ShareDir-1.114 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1594041 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-File-ShareDir-1.114-1. ||fc29 Resolution|--- |RAWHIDE Last Closed||2018-06-22 03:37:34 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/UOZT2ID3W456Z43VZOORVWOQB63VVT5B/
