date:20180618

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
___
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/TCPAABXLN7ZIIGD774GRYVXWMLAKMHAI/

Re: Packages with compiled python files outside of /usr/lib*/python8

2018-06-18 Thread Miro Hrončok


On 18.6.2018 11:04, Milan Crha wrote:

Hi,

On Mon, 2018-06-18 at 10:46 +0200, Miro Hrončok wrote:

evolution-tests:


oh, I see, I do not build/install them locally, thus I didn't notice
them in my $PREFIX. I'll update the evolution package spec file.


What Python are those files for actually? Are they imported or executed?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/I2GZTRGLXMBFEKKN42XHBPTBHPNXRG5O/

Re: Packages with compiled python files outside of /usr/lib*/python8

2018-06-18 Thread Milan Crha

On Mon, 2018-06-18 at 11:19 +0200, Miro Hrončok wrote:
> What Python are those files for actually? Are they imported or
> executed?

Hi,
I do not speak pythonish, I'm sorry, but from what I recall they had
been added as some sort of unit tests. I think they are meant to be
executed only, but I do not know how they are used by 3rd-parties, if
at all. The corresponding .test files execute them using `behave`:

  [Test]
  Type=session-exclusive
  Exec=behave /usr/libexec/evolution/installed-tests -t view_shortcuts -k -f 
html -o view_shortcuts.html -f plain

Hope it helps.
Bye,
Milan
___
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/UBXUJG6IO2ESSAYAL55MYP66ESVWE2PM/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On Sun, Jun 17, 2018 at 11:13:39PM +0100, Ian Malone wrote:
> On 16 June 2018 at 13:50, Björn Persson  wrote:
> > Tomasz Kłoczko wrote:
> >> On Fri, 15 Jun 2018 at 23:21, Björn Persson  wrote:
> >> [..]
> >> > Don't forget that if your proof of concept can be modified to either
> >> > overwrite or append to ~/.bashrc, then it's irrelevant to this debate.
> >>
> >> before ~/.bashrc is executed many other scripts  executions
> >> already is finished
> >
> > This is true and completely irrelevant.
> >
> >> Whatever you want to do over you account session or profile scripts it
> >> is already _to late_.
> >> Is that clear now?
> >
> > No it's not clear. I have no idea why you're rambling about the order
> > in which Bash executes its startup files. The order doesn't matter,
> > especially since the hypothetical attacker is supposedly unable to
> > modify those files.
> >
> > You claimed to have a proof of concept that would demonstrate how some
> > security hole can be exploited if and only if ~/.local/bin is listed
> > before /usr/bin in PATH. I asked you to post your proof of concept. You
> > didn't. I will therefore conclude that you don't actually have one.
> >
> 
> 
> Well, two things:
> 
> 1. For example, a kiosk mode, where the home directory is wiped each
> login would be made less secure. The profile for the GUI is set at
> login, so writing .bash_profile has no effect on the GUI environment,
> but an attacker able to place files where the user has write
> permission could mask system binaries.

Even if .bash_profile is not always read, .bashrc is read every time
a shell is started (OK, not "every time", but often enough). So for
example if I open a new tab in the terminal, or run some scripting plugin
from an editor, etc, the effect is the same as overwriting .bash_profile.

But more generally, if one uses a public kiosk that somebody else had
logged into first, for *any* purpose requiring security, that is a
grave mistake already. How would one even know that the gui they are
accessing hasn't been substituted wholesale?

> But a more major worry for me here, the reason I'm bothering to reply
> to a thread about setting paths (though to be honest, someone who
> doesn't understand how to do that may not have much business
> installing unpackaged software, particularly when the examples are
> developer tools):
> 
> 2. The fact that a proof of concept cannot be provided is not a proof
> that a change you make is secure. Take Spectre; that vulnerability has
> been around for decades with no public proof of concept, or even
> knowledge there was a vulnerability, yet it can be exploited from
> Javascript in a browser. So this repeated insistence on providing a
> proof of concept before a security concern is taken seriously is
> fundamentally wrong, and I would be concerned to see it applied
> elsewhere in Fedora.

In this case we understand what the change in behaviour means, we just
seem to disagree on how significant this is. We even know how any such
exploit would look. The calls to provide a POC have the intent to take
any such POC and tweak it to modify .bash_profile/.bashrc/.i18n instead,
and thus turn the discussion around by showing that $PATH order is
irrelevant to the attack.

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/6F643BHFN4DN5YD2XHVK5I5B7QC4I3KA/

Re: Packages with compiled python files outside of /usr/lib*/python8

2018-06-18 Thread Miro Hrončok


On 18.6.2018 11:45, Milan Crha wrote:

On Mon, 2018-06-18 at 11:19 +0200, Miro Hrončok wrote:

What Python are those files for actually? Are they imported or
executed?


Hi,
I do not speak pythonish, I'm sorry, but from what I recall they had
been added as some sort of unit tests. I think they are meant to be
executed only, but I do not know how they are used by 3rd-parties, if
at all. The corresponding .test files execute them using `behave`:

   [Test]
   Type=session-exclusive
   Exec=behave /usr/libexec/evolution/installed-tests -t view_shortcuts -k -f 
html -o view_shortcuts.html -f plain

Hope it helps.


1. behave is Python 2 (you might want to check if it works with behave-3 
and switch to Python 3 if it works)


2. behave does not create pyc files, so IMHO you do not need to 
bytecompile those with any Python

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/COXWVDZMY3IOUWI5ALCXAI26HUGIM7EW/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Ian Malone

On 18 June 2018 at 11:27, Zbigniew Jędrzejewski-Szmek  wrote:
> On Sun, Jun 17, 2018 at 11:13:39PM +0100, Ian Malone wrote:
>> On 16 June 2018 at 13:50, Björn Persson  wrote:
>> > Tomasz Kłoczko wrote:
>> >> On Fri, 15 Jun 2018 at 23:21, Björn Persson  wrote:
>> >> [..]
>> >> > Don't forget that if your proof of concept can be modified to either
>> >> > overwrite or append to ~/.bashrc, then it's irrelevant to this debate.
>> >>
>> >> before ~/.bashrc is executed many other scripts  executions
>> >> already is finished
>> >
>> > This is true and completely irrelevant.
>> >
>> >> Whatever you want to do over you account session or profile scripts it
>> >> is already _to late_.
>> >> Is that clear now?
>> >
>> > No it's not clear. I have no idea why you're rambling about the order
>> > in which Bash executes its startup files. The order doesn't matter,
>> > especially since the hypothetical attacker is supposedly unable to
>> > modify those files.
>> >
>> > You claimed to have a proof of concept that would demonstrate how some
>> > security hole can be exploited if and only if ~/.local/bin is listed
>> > before /usr/bin in PATH. I asked you to post your proof of concept. You
>> > didn't. I will therefore conclude that you don't actually have one.
>> >
>>
>>
>> Well, two things:
>>
>> 1. For example, a kiosk mode, where the home directory is wiped each
>> login would be made less secure. The profile for the GUI is set at
>> login, so writing .bash_profile has no effect on the GUI environment,
>> but an attacker able to place files where the user has write
>> permission could mask system binaries.
>
> Even if .bash_profile is not always read, .bashrc is read every time
> a shell is started (OK, not "every time", but often enough). So for
> example if I open a new tab in the terminal, or run some scripting plugin
> from an editor, etc, the effect is the same as overwriting .bash_profile.
>

But these assume you are only attacking the shell. The system path is
used to resolve commands started from the gui too, independent of
bash.

> But more generally, if one uses a public kiosk that somebody else had
> logged into first, for *any* purpose requiring security, that is a
> grave mistake already. How would one even know that the gui they are
> accessing hasn't been substituted wholesale?
>

This is a misdirection. We can still worry about an attack on a user
logging into a clean profile (the case I was discussing), or from the
point of view of the kiosk administrator concerned with ensuring the
security of their users, the system itself and the network it's
attached to. To put it another way, you probably use a proprietary CPU
in your computer, how do you know it's not compromised? Why do we
worry at all about security if you can't guarantee that?

>> But a more major worry for me here, the reason I'm bothering to reply
>> to a thread about setting paths (though to be honest, someone who
>> doesn't understand how to do that may not have much business
>> installing unpackaged software, particularly when the examples are
>> developer tools):
>>
>> 2. The fact that a proof of concept cannot be provided is not a proof
>> that a change you make is secure. Take Spectre; that vulnerability has
>> been around for decades with no public proof of concept, or even
>> knowledge there was a vulnerability, yet it can be exploited from
>> Javascript in a browser. So this repeated insistence on providing a
>> proof of concept before a security concern is taken seriously is
>> fundamentally wrong, and I would be concerned to see it applied
>> elsewhere in Fedora.
>
> In this case we understand what the change in behaviour means, we just
> seem to disagree on how significant this is. We even know how any such
> exploit would look. The calls to provide a POC have the intent to take
> any such POC and tweak it to modify .bash_profile/.bashrc/.i18n instead,
> and thus turn the discussion around by showing that $PATH order is
> irrelevant to the attack.
>

Fundamentally flawed approach, since you are assuming you know the
constraints an attacker is working under, here you assume that they
are able to freely write to all locations the user can access. This
may not always be the case. An attacker's first job is to leverage a
weakness to gain that control. As I mentioned what worries me most is
this attitude that you must be smarter than the attacker and that you
do not need to think defensively because of that.


-- 
imalone
http://ibmalone.blogspot.co.uk
___
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/OKVKAN4NTSNP5WAWGFSEFLUWUABDU47H/

Re: Intel's Clear Linux optimizations

2018-06-18 Thread Manas Mangaonkar

Just a update,Ended up with a somewhat broken kernel that had performance
issues with the lts patches even after lot of tweaking.Apparently the clear
linux base kernel source tree is stable and working with latest Linux
kernels. Still working on it incase anyone is wondering if this was
abandoned.

On Tue, May 22, 2018 at 11:48 AM, Manas Mangaonkar <
manasmangaon...@gmail.com> wrote:

>
> >The upstream non LTS kernels have had the mitigation for
>> >meltdown/spectre longer than LTS and they likely have more robust
>> >implementations. All Fedora releases have had fixes for some time.
>>
>
> I meant the clear linux kernel,they seem to have diff kernel bundles
> and i want to go with the Lts one.
>
>
>>
>> > To get your feet wet, you could build a standard Fedora kernel using
>> > one of these processes.
>> >
>> > https://fedoraproject.org/wiki/Building_a_custom_kernel
>> >
>> > https://docs.fedoraproject.org/quick-docs/en-US/kernel/build
>> -custom-kernel.html
>> >
>> > https://fedoraproject.org/wiki/Building_a_custom_kernel/Source_RPM
>> >
>> > Then, when you have that working, use the same procedure to build the
>> > clear linux kernel from source.  That way you know that both compile
>> > individually.
>> >
>> > The final step is just to ensure that once the Fedora kernel is patched
>> > to support clear linux, it compiles also.  Then it will support the
>> > Fedora enhancements to the kernel that haven't made it upstream yet
>> > (and might never), and will run on any fedora system.
>> >
>> > I don't know if the clear linux kernel is compatible with other
>> > architectures and video hardware.  If it isn't, it can only be run on
>> > x86_64 with intel video hardware (no nvidia or amd additional video
>> > hardware).  If it isn't compatible with other architectures or video
>> > hardware, I don't think it makes sense to compile it as a Fedora
>> > kernel, so you would be done after you get it building from source.
>> > Not sure how useful such a kernel would be.
>> > ___
>> > 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.or
>> g/archives/list/devel@lists.fedoraproject.org/message/SDS3J7
>> 23DDZB6VNXHD2DVD2STHC7TDSY/
>> ___
>> 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.or
>> g/archives/list/devel@lists.fedoraproject.org/message/BA3RBX
>> Y3PYJ4U2H5LCLJ6ZWTX4FITDGS/
>
>
> The clear linux does run on amd hardware,at phoronix they tried it on the
> new eypec cpu line from amd. Performs well and wont hinder performance.
>
> > hardware, I don't think it makes sense to compile it as a Fedora
> > kernel, so you would be done after you get it building from source.
> > Not sure how useful such a kernel would be.
>
> No nvidia or amd gpu support though.But for those who want pure computing
> power for containers etc this can be a solid option,it does perform much
> better than other linux distro kernels.
>
> I find this interesting,and a fun learning experience to get my feet wet.
>
___
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/CXC37OK755JEDOQ3NX76NBKO6R32MJM6/

upcoming systemd-239 release — call for testing

Hi all,

we plan to release systemd-239 wednesday-ish and it will be landing in
rawhide. There's a bunch of new functionality, see
https://github.com/systemd/systemd/blob/master/NEWS. As always, the
majority of commits is cleanups and bugfixes and the polishing of
existing functionality. A big new feature is "portable services",
currently in preview mode. There are man pages, but an introductory
blog story is planned around the time of the release, so you might
want to wait for that.

Please give it a try and report any bugs either in bugzilla [1] or
upstream [2]. For testing, rpms are available from copr:
https://copr.fedorainfracloud.org/coprs/zbyszek/systemd/build/768345/.

Zbyszek

PS. There seems to be a regression in copr with building from src.fp.o
git. Previously I was able to point copr at the right git URL and it
would build the package. That fails [3] now with a strange error about
missing "http://None"; prefix. Is this a known problem?

[1]
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=systemd&release=rawhide
[2] https://github.com/systemd/systemd/issues/new
[3] https://copr.fedorainfracloud.org/coprs/zbyszek/systemd/build/768342/
http://copr-dist-git.fedorainfracloud.org/per-task-logs/768342.log

https://copr-be.cloud.fedoraproject.org/results/zbyszek/systemd/srpm-builds/00768342/builder-live.log
___
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/OSGKZYCVS5Z3QSEVN72H3OCWHQ7FQVYD/

Re: upcoming systemd-239 release — call for testing

2018-06-18 Thread Miroslav Suchý

Dne 18.6.2018 v 14:16 Zbigniew Jędrzejewski-Szmek napsal(a):
> PS. There seems to be a regression in copr with building from src.fp.o
> git. Previously I was able to point copr at the right git URL and it
> would build the package. That fails [3] now with a strange error about
> missing "http://None"; prefix. Is this a known problem?

Copr cannot construct SRPM because of:

Wrote: /var/lib/copr-rpmbuild/results/tmpf3uvor6m/systemd.spec
stderr: error: Unable to open 
/var/lib/copr-rpmbuild/results/tmpf3uvor6m/triggers.systemd: No such file or 
directory
can't parse specfile

triggers.systemd is not in the tarbal and not in the dist-git.

You can debug it locally by executing

/usr/bin/copr-rpmbuild --verbose --drop-resultdir --srpm --build-id 768342

on your workstation and check content of the directories you get in output.

Miroslav
___
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/EKB6UAPRZO4ERS4OKFUIM3CFP25FA3HD/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Tomasz Kłoczko

On Mon, 18 Jun 2018 at 12:18, Ian Malone  wrote:
[..]
> > Even if .bash_profile is not always read, .bashrc is read every time
> > a shell is started (OK, not "every time", but often enough). So for
> > example if I open a new tab in the terminal, or run some scripting plugin
> > from an editor, etc, the effect is the same as overwriting .bash_profile.
> >
>
> But these assume you are only attacking the shell. The system path is
> used to resolve commands started from the gui too, independent of
> bash.

In context of so called of "Nobody expects The Spanish Inquisition"
effect (understood as OOTB distro resources using executables and/or
data and/or configuration files which are not part of the regular
distribution) it is not only about targeting bash.
Many applications reads own env variables and passes $PATH down to
executed processes (this depends on variant exec() syscall used to
execute other processes). If application A will be executing script
interpreter which result will be used byt this A application it may
mean targeting exactly such application.

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!

And here is kind od "binary effect" of the "Nobody expects The Spanish
Inquisition" effect.
There are some number of properties of the current packages which
separately *does not increases risk*.
However, mixed with other packages properties on interacting with
those resources they are forming context with *non-zero risk*.
And it is one of those reasons why it was so easy to see those consequences :)

Simple  .. most of the people do not expect that 0+0 suddenly will be
>=0. Isn't it?
Truth is that here works a bit different type of algebra.
Whoever knows mathematics above some level knows that it is nothing
unusual to have such outcome.
By define "+" operation as a+b+ more times will be used "+"
operation than greated non-zero value will be even when a=b=0.

Another small exempla of this whole effect could be provided by
executing most of the python scripts.
In output of the "strace -e trace=file dnf" you will be able to find
fragments like:

stat("/usr/bin", {st_mode=S_IFDIR|0555, st_size=43016, ...}) = 0
stat("/usr/bin/dnf/__init__.cpython-36m-x86_64-linux-gnu.so",
0x7ffee21f8970) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/dnf/__init__.abi3.so", 0x7ffee21f8970) = -1 ENOTDIR
(Not a directory)
stat("/usr/bin/dnf/__init__.so", 0x7ffee21f8970) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/dnf/__init__.py", 0x7ffee21f8970) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/dnf/__init__.pyc", 0x7ffee21f8970) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/dnf", {st_mode=S_IFREG|0755, st_size=1942, ...}) = 0

stat("/usr/bin", {st_mode=S_IFDIR|0555, st_size=43016, ...}) = 0
stat("/usr/bin/locale/__init__.cpython-36m-x86_64-linux-gnu.so",
0x7ffee21f40f0) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/locale/__init__.abi3.so", 0x7ffee21f40f0) = -1 ENOTDIR
(Not a directory)
stat("/usr/bin/locale/__init__.so", 0x7ffee21f40f0) = -1 ENOTDIR (Not
a directory)
stat("/usr/bin/locale/__init__.py", 0x7ffee21f40f0) = -1 ENOTDIR (Not
a directory)
stat("/usr/bin/locale/__init__.pyc", 0x7ffee21f40f0) = -1 ENOTDIR (Not
a directory)
stat("/usr/bin/locale", {st_mode=S_IFREG|0755, st_size=63888, ...}) = 0

or lines like:

openat(AT_FDCWD, "/usr/bin/pyvenv.cfg", O_RDONLY) = -1 ENOENT (No such
file or directory)
openat(AT_FDCWD, "/usr/pyvenv.cfg", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat("/usr/bin/pyvenv.cfg", 0x7ffebc328a60) = -1 ENOENT (No such file
or directory)
stat("/usr/pyvenv.cfg", 0x7ffebc328a60) = -1 ENOENT (No such file or directory)

None of those paths are used in the dnf own code ..

If you know that exact application is using exact location to find
executables, scripting languages extensions/modules or configuration
files BEFORE checking well known paths in which other packages are
installing those types of resources you can use those locations to
alter how exact application is working without touching to many bells.

I've already mention about risk of altering of what for example
gcc/g++ is producing on Fedora build systems.
You can drop in /usr/local/bin most of the executables used during
building packages processes and you will be not be able to see
anything new/obvious looking on the build logs. It will be especially
easy in case of all packages build frameworks which are suppressing
verbosity level where are only logged details in a way like:
"CC: file.c"
"LD: prog"
This is why I've mention few times on this list about take care of
enable MAXIMUM possible verbosity level in build logs on Fedora build
systems.

Despite non-zero

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-18 Thread Lennart Poettering

On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:

> The cited BLS spec is the original one, not the more thoroughly
> discussed and thought through variant by Matthew Garrett [1] some
> years ago.

Quite frankly, as one of the authors of the original BLS spec, I can'd
say Matthew's version was much discussed with me...

I mean, I am open to extending the spec, but we should do this bit by
bit.

Zbigniew suggested to move the spec into docbook or markdown format,
and then accept changes via usual github PRs. If there's interest
still in extending the spec with some of Matthew's ideas we can
certainly look into that, but in general I'd actually prefer to reduce
the size of the spec if possible, and drop as many bits of it as we
can, i.e. the stuff noone implements anyway.

> The cited BLS spec requires $BOOT be VFAT, are we doing that?

Why would we? I mean the idea is that $BOOT can be shared among
multiple OSes installed. Which means one really should settle on a
format anyone can read. And VFAT certainly qualifies as that, most
other file systems do not.

> Are we going to stop doing the diabolical (and widespread) nested
> mount nonsense, e.g. /boot/efi? Are we getting rid of the persistent
> mounting of these volumes in favor of mounting/unmounting dynamically
> only by the programs that are authorized to make changes to these
> volumes?

So, in systemd we ship a generator that automatically establishes
automount points for the ESP. It will preferably use /efi as mount
point if it exists and is empty. If it doesn't exist or isn't
empty it will use /boot — if that exists or is empty. If neither exist
or are empty it won't do anything. Using an automount point for this
has many benefits:

1) The chance that the ESP remains in a clean state is maximized, as
   the file system is unmounted whenever possible, and only mounted
   for a short time window around actual disk accesses. This is the
   behaviour you really want for something as fragile as the ESP.

2) It's compatible with current behaviour, as the path is always
   accessible under a fixed name, requiring no explicit mounting.

3) There's no need to configure any lines for the ESP in /etc/fstab
   anymore. Instead the system will discover the ESP automatically and
   make it available. This means the installer can be simpler, and
   things are generally more robust as /efi (or /boot) will follow
   what is in place, instead of require a separate layer of
   configuration that has a good chance of getting out of sync.

I'd love to see Fedora adopt this generator. Primarily this would mean
some chnages to anaconda I guess. It would make things simpler and
more robust. That said, the generator only cares about the ESP, not
for cases where $BOOT is backed by any other partition.

See systemd-gpt-auto-generator(8) for details about all of this.

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/KQFJC3F4YATMM5BJ76IS7Z2NGVL2GQNO/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Vít Ondruch



Dne 18.6.2018 v 00:13 Ian Malone napsal(a):
> On 16 June 2018 at 13:50, Björn Persson  wrote:
>> Tomasz Kłoczko wrote:
>>> On Fri, 15 Jun 2018 at 23:21, Björn Persson  wrote:
>>> [..]
 Don't forget that if your proof of concept can be modified to either
 overwrite or append to ~/.bashrc, then it's irrelevant to this debate.
>>> before ~/.bashrc is executed many other scripts  executions
>>> already is finished
>> This is true and completely irrelevant.
>>
>>> Whatever you want to do over you account session or profile scripts it
>>> is already _to late_.
>>> Is that clear now?
>> No it's not clear. I have no idea why you're rambling about the order
>> in which Bash executes its startup files. The order doesn't matter,
>> especially since the hypothetical attacker is supposedly unable to
>> modify those files.
>>
>> You claimed to have a proof of concept that would demonstrate how some
>> security hole can be exploited if and only if ~/.local/bin is listed
>> before /usr/bin in PATH. I asked you to post your proof of concept. You
>> didn't. I will therefore conclude that you don't actually have one.
>>
>
> Well, two things:
>
> 1. For example, a kiosk mode, where the home directory is wiped each
> login would be made less secure.

Forgive my ignorance, but where is the option to install Fedora in Kiosk
mode? I am asking, because I am not aware about any option like this,
hence this needs IMO some configuration and if you configure the
computer to run in Kiosk mode, then you can certainly modify the PATH to
improve security of such setup.


Vít
___
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/J33IAEELIZPPCGKZC7BMNKARVJOFWEQ3/

Re: Packages which call install-info in scriptlets

> "JJ" == Jerry James  writes:

JJ> One reason to do this is that the info file does not contain the
JJ> entry, so there is nothing to extract.

Surely it would be better to fix the info file, wouldn't it?

 - J<
___
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/RH7DBGU6P3H6ZUTIUBA5ZCHJ66F37RL3/

Re: Packages which call install-info in scriptlets

> "AM" == Andrea Musuruane  writes:

AM> I think rpmlint should be amended. Now I get "E:
AM> info-files-without-install-info-postun" on F28.

Yes, rpmlint needs to be told to ignore this issue on F28+.

 - J<
___
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/HJVDI35UPA5BTOGPX3E7DL5T2ERMGHSL/

Re: Packages which call install-info in scriptlets

> "PP" == Petr Pisar  writes:

PP> What about uninstallation?

That is covered by the existing triggers:

%transfiletriggerpostun -n info -- %{_infodir}
[ -f %{_infodir}/dir ] && %{_sbindir}/fix-info-dir --delete %{_infodir}/dir 
&>/dev/null

If fix-info-dir is not working as documented (where --delete explicitly
is supposed to remove things from the dir node which don't exist) then
that would be worthy of a bug against texinfo.

 - J<
___
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/CIACIXS5OMLNKD2ZSTHBPOKANBVEFH63/

Re: Packages which call install-info in scriptlets

2018-06-18 Thread Petr Pisar

On 2018-06-18, Jason L Tibbitts III  wrote:
>> "PP" == Petr Pisar  writes:
>
>PP> What about uninstallation?
>
> That is covered by the existing triggers:
>
> %transfiletriggerpostun -n info -- %{_infodir}
> [ -f %{_infodir}/dir ] && %{_sbindir}/fix-info-dir --delete %{_infodir}/dir 
> &>/dev/null
>
> If fix-info-dir is not working as documented (where --delete explicitly
> is supposed to remove things from the dir node which don't exist) then
> that would be worthy of a bug against texinfo.
>
https://bugzilla.redhat.com/show_bug.cgi?id=1592433
___
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/CGO5UBFEDYVGHLL4HAUJMCVNF322ZKPH/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Tomasz Kłoczko

On Mon, 18 Jun 2018 at 14:58, Vít Ondruch  wrote:
[..]
> Forgive my ignorance, but where is the option to install Fedora in Kiosk
> mode? I am asking, because I am not aware about any option like this,
> hence this needs IMO some configuration and if you configure the
> computer to run in Kiosk mode, then you can certainly modify the PATH to
> improve security of such setup.

https://fedoraproject.org/wiki/Fedora_Kiosk
And no .. you cannot at the moment do to much about $PATH because
modifications about this env variable are spread across multiple
packages.
In most of the cases this cannot be changed without patching source
code and recompile exact packages.

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/RLG6KHAVXOJZSVAEWM5O2Y7PXYOM7OZA/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-18 Thread Ondřej Lysoněk

Hi,

On 14.6.2018 12:06, Jan Kurik wrote:
> = Proposed System Wide Change: Make BootLoaderSpec the default =
> https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
> 
> 
> Owner(s):
>   * Javier Martinez Canillas 
>   * Peter Jones 
> 
> 
> Use BootLoaderSpec fragment files by default to populate the
> bootloaders boot menu entries.
> 
> 
> 
> == Detailed description ==
> The [https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
> Boot Loader Specification (BLS)] defines a scheme and file format to
> manage boot loader configuration for each boot option in a drop-in
> directory, without the need to manipulate bootloader configuration
> files. These drop-in directories are the standard on Linux nowadays,
> so the goal is to also extend this concept for boot menu entries.
> This is especially important in Fedora because the same bootloader is
> not used in all architectures. GRUB 2 is used in most of them, but
> there are others such as zipl for s390x and Petitboot for ppc64le. Not
> all bootloaders have the same configuration file format, so there is a
> need for an indirection level and per bootloader specific logic to
> edit these configuration files, when adding or removing a boot entry.
> The current component that does this work is grubby, that has support
> for all the different bootloader configuration file formats and
> manipulates them on kernel installation or uninstallation. Besides
> manipulating the bootloader configuration files, grubby also does
> other things like running dracut to create an initial ramdisk image.
> Fedora already has a lot of infrastructure in place to not require
> modifying bootloader configuration files for boot menu entries. The
> BootLoaderSpec and drop-in BLS fragments can be used instead, and the
> kernel-install script can do any additional task that is currently
> done by grubby. The kernel-install script has a pluggable design that
> uses a drop-in directory for scripts to extend its functionality. So
> if needed, any bootloader specific logic can be implemented as
> kernel-install scripts.
> With this setup the bootloader configuration could be static and not
> modified after installation.
> The missing piece was the lack of BLS support on all the supported
> bootloaders, but all of them have support to parse BLS fragments now.
> So we can default to install BLS files on kernel installation and drop
> grubby.

I noticed the official spec defines a field named "machine-id". AFAICS,
GRUB2 doesn't implement that option, but it supports a field named "id".
Are these used for the same thing? If they are, why are they named
differently?

I also have a question regarding interoperability with distros which do
not support BLS. Suppose I install Fedora with BLS enabled and then
beside that install some distro which doesn't support BLS. The second
distro will probably install its own bootloader. Will I be able to boot
Fedora from the bootloader installed by the second OS?

Thanks.

Best regards
Ondřej Lysoněk
___
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/JA5JQNKSVKMP5ECYSGVTN656IA3VC67C/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Vít Ondruch

Dne 18.6.2018 v 16:30 Tomasz Kłoczko napsal(a):
> On Mon, 18 Jun 2018 at 14:58, Vít Ondruch  wrote:
> [..]
>> Forgive my ignorance, but where is the option to install Fedora in Kiosk
>> mode? I am asking, because I am not aware about any option like this,
>> hence this needs IMO some configuration and if you configure the
>> computer to run in Kiosk mode, then you can certainly modify the PATH to
>> improve security of such setup.
> https://fedoraproject.org/wiki/Fedora_Kiosk
> And no .. you cannot at the moment do to much about $PATH because
> modifications about this env variable are spread across multiple
> packages.
> In most of the cases this cannot be changed without patching source
> code and recompile exact packages.
>
> kloczek

It does not look to be maintained ...

V.
___
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/MCJKGWASLBBL3N55GOCI6IP56AZH4P3S/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-18 Thread Ondřej Lysoněk

Hi,

On 18.6.2018 15:27, Lennart Poettering wrote:
> On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:
> 
>> The cited BLS spec is the original one, not the more thoroughly
>> discussed and thought through variant by Matthew Garrett [1] some
>> years ago.
> 
> Quite frankly, as one of the authors of the original BLS spec, I can'd
> say Matthew's version was much discussed with me...
> 
> I mean, I am open to extending the spec, but we should do this bit by
> bit.
> 
> Zbigniew suggested to move the spec into docbook or markdown format,
> and then accept changes via usual github PRs. If there's interest
> still in extending the spec with some of Matthew's ideas we can
> certainly look into that, but in general I'd actually prefer to reduce
> the size of the spec if possible, and drop as many bits of it as we
> can, i.e. the stuff noone implements anyway.

It would be great if we could extend the spec with optional support for
multiple initrd images (the Tuned daemon depends on that). Fedora's
GRUB2 already supports multiple initrd images (it allows specifying
multiple lines with the "initrd" key), but I'd like to make sure that
whoever implements BLS in the future and decides to support multiple
initrds will not choose a different syntax for it. Would you be open to
extending the spec with that?

Thanks.

Best regards
Ondřej Lysoněk
___
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/UPTBATX3EUGUJFEDQS4DDHB7GSVI5BA5/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-18 Thread Peter Jones

On Thu, Jun 14, 2018 at 12:40:50PM -0700, Adam Williamson wrote:
> On Thu, 2018-06-14 at 15:10 -0400, Matthew Miller wrote:
> > On Thu, Jun 14, 2018 at 11:51:33AM -0700, Adam Williamson wrote:
> > > > ** Have a grubby wrapper for backward compatbility that manipulates BLS 
> > > > files.
> > > 
> > > What exactly is the plan for upgrades, here?
> > 
> > I *assume* it's what the "grubby wrapper" is there for?
> 
> Yeah, I was hoping for more details :)

The grubby wrapper is actually to provide a transition plan to external
scripts and tools that are using grubby, but which we're not aware of.
Right now the plan is that it'll be provided as part of grubby, while we
phase out the grubby code that's so painful.  It basically provides
things like telling you which kernel is selected or setting the option
for what to boot next time, without handling the crazy parts of writing
config files or calling out to dracut, or all that stuff.

The general plan for upgrades is a program we've written named
grub2-switch-to-blscfg, which:

- sets GRUB_ENABLE_BLSCFG=true in /etc/default/grub
- creates bls config files for any kernels that aren't already providing
  them
- re-runs grub2-mkconfig to generate a BLS-aware grub.cfg

For f28 the plan is that the user can switch by running that manually as
root, or by removing the grubby package, which will call it in %postun.
This gives users ability to switch back in the f28 time-frame in the
event they hit some corner cases we haven't solved or seen yet, and
gives us time to get reasonable feedback before phasing out non-bls
configs.  Then, for f29, we'll obsolete grubby itself and only have the
compatibility version.

So that's the upgrade plan.

-- 
  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/3D4VJXRC3QG5STJMLQCXBGLJQRPOTDXZ/

Re: F29 System Wide Change: Make BootLoaderSpec the default

On Mon, Jun 18, 2018 at 11:17:50AM -0400, Peter Jones wrote:
> On Thu, Jun 14, 2018 at 12:40:50PM -0700, Adam Williamson wrote:
> > On Thu, 2018-06-14 at 15:10 -0400, Matthew Miller wrote:
> > > On Thu, Jun 14, 2018 at 11:51:33AM -0700, Adam Williamson wrote:
> > > > > ** Have a grubby wrapper for backward compatbility that manipulates 
> > > > > BLS files.
> > > > 
> > > > What exactly is the plan for upgrades, here?
> > > 
> > > I *assume* it's what the "grubby wrapper" is there for?
> > 
> > Yeah, I was hoping for more details :)
> 
> The grubby wrapper is actually to provide a transition plan to external
> scripts and tools that are using grubby, but which we're not aware of.

I wonder if this providing the compat interface is worth the trouble.
If there are those external scripts and tools, it's impossible to know
that they still work with the replacement, unless the replacement
implements everything *exactly* as the original, but that's pretty
much impossible considering that the new scheme is so much different.

So maybe it'd be both less work *and* safer, to just keep grubby as is,
allow existing installations to continue using grubby, and switch
all new installations to not use it at all and not even install it there?

F29 is not that far out actually, and I think it'd be better to devote
available resource to the new implementation, instead of any compat
measures.

Zbyszek

> Right now the plan is that it'll be provided as part of grubby, while we
> phase out the grubby code that's so painful.  It basically provides
> things like telling you which kernel is selected or setting the option
> for what to boot next time, without handling the crazy parts of writing
> config files or calling out to dracut, or all that stuff.
> 
> The general plan for upgrades is a program we've written named
> grub2-switch-to-blscfg, which:
> 
> - sets GRUB_ENABLE_BLSCFG=true in /etc/default/grub
> - creates bls config files for any kernels that aren't already providing
>   them
> - re-runs grub2-mkconfig to generate a BLS-aware grub.cfg
> 
> For f28 the plan is that the user can switch by running that manually as
> root, or by removing the grubby package, which will call it in %postun.
> This gives users ability to switch back in the f28 time-frame in the
> event they hit some corner cases we haven't solved or seen yet, and
> gives us time to get reasonable feedback before phasing out non-bls
> configs.  Then, for f29, we'll obsolete grubby itself and only have the
> compatibility version.
> 
> So that's the upgrade plan.

___
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/LVY2QTZWFRGFWFRJ3A2CINAUZXS3PLGC/

New FESCo Meeting Time and Ticket Policy

2018-06-18 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

At today's FESCo meeting, we selected a new meeting time to accommodate the
schedules of the newly-elected members. As such, FESCo meetings for the next
cycle will be taking place on Mondays at 1500 UTC (1100 EDT, 1700 CEST).

However, in the interest of having shorter and possibly less-frequent
meetings, FESCo has opted to change its policy regarding ticket-handling,
effective immediately. The new policy is as follows:

* Most FESCo votes will be performed in the tickets. FESCo members will have
one week[1] from the creation of the ticket to vote. So long as at least three
members have voted, the majority of votes at the end of that week will be
counted as the result. If three votes are not received in the first week,
voting will be extended by one additional week and the minimum required
responses reduced to a single vote. If by the end of that second week no votes
have been counted, it will be treated as a vote *against* any change requested
by the reporter, thus preserving the current status however it stands. We do
not expect this clause to ever be invoked.

* Within the voting period, any FESCo member may add the 'meeting' keyword if
they believe that a proper decision will require in-person discussion in a
meeting. That topic will then be added to the agenda for the next regularly
scheduled meeting. No meeting will be held if there are no agenda items listed
by noon UTC of the preceding business day.

-BEGIN PGP SIGNATURE-
Version: Mailvelope v2.2.2
Comment: https://www.mailvelope.com

wkYEAREIABAFAlsj8jYJEHolVWI2uqOjAACxgwCfY/59iYVCDUmPgZKShaz8
d9ikSpQAn3m1b6IPrsaWTUNeB3PoWL+t+Zsl
=BdWE
-END PGP SIGNATURE-
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org/message/I5TGAFIFKOPQOHZOQE2DRI4V2PZ5FITZ/
___
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/I5TGAFIFKOPQOHZOQE2DRI4V2PZ5FITZ/

[Action Required] Node.js 10.x and the Fedora 29 schedule

2018-06-18 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This message is directed at anyone who maintains a Node.js package in Fedora.

On Friday, FESCo approved the Fedora 29 System-Wide Change to move the default
Node.js interpreter to the 10.x LTS stream. This means that we will need to
ensure that any NPM packages that are present in Rawhide must work on 10.x.

What you need to do if

== ... your current package works fine with both Node.js 8.x and 10.x ==
No action required.

== ... your current package doesn't work with 10.x ==

A) It has an upstream release that does (or you can patch it to work)
- - Prepare the upstream package and build it in Rawhide during the week of June
  25th through the 29th. I will update the Node.js interpreter in Rawhide
  sometime on Friday, June 22nd so it will be in the buildroot.

B) It cannot be made to work with Node.js 10.x at all
- - If this package is still valuable to have when people are using the 8.x
  module stream, contact me directly and we will coordinate including it in the
  module.
- - If this package is no longer useful, retire it by June 29th.
-BEGIN PGP SIGNATURE-
Version: Mailvelope v2.2.2
Comment: https://www.mailvelope.com

wkYEAREIABAFAlsnm1oJEHolVWI2uqOjAAB7nQCgiuZkpu2fDDHM6F47I8GN
nD81quEAoIJtHaqfWscpZ/ZfjVRobMa3/NM4
=F1U7
-END PGP SIGNATURE-
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org/message/EAV65L3J65E5YAGGVMLVC7MZDBU64HZ6/
___
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/EAV65L3J65E5YAGGVMLVC7MZDBU64HZ6/

Re: upcoming systemd-239 release — call for testing

On Mon, Jun 18, 2018 at 02:54:07PM +0200, Miroslav Suchý wrote:
> Dne 18.6.2018 v 14:16 Zbigniew Jędrzejewski-Szmek napsal(a):
> > PS. There seems to be a regression in copr with building from src.fp.o
> > git. Previously I was able to point copr at the right git URL and it
> > would build the package. That fails [3] now with a strange error about
> > missing "http://None"; prefix. Is this a known problem?
> 
> Copr cannot construct SRPM because of:
> 
> Wrote: /var/lib/copr-rpmbuild/results/tmpf3uvor6m/systemd.spec
> stderr: error: Unable to open 
> /var/lib/copr-rpmbuild/results/tmpf3uvor6m/triggers.systemd: No such file or 
> directory
> can't parse specfile
> 
> triggers.systemd is not in the tarbal and not in the dist-git.

Thanks for looking into this.

rpm does not allow reading that file from the tarball, because it
wants it to be available for %include when the spec file is parsed.
That's why I put the in git directly.

It *is* in dist-git:
https://src.fedoraproject.org/rpms/systemd/blob/master/f/triggers.systemd

This certainly worked before with that file being there. I added that file
in April 2016, and I built systemd in copr successfully as recently as
2 months ago. This seems to be a regression.

Zbyszek

> You can debug it locally by executing
> 
> /usr/bin/copr-rpmbuild --verbose --drop-resultdir --srpm --build-id 768342
> 
> on your workstation and check content of the directories you get in output.
___
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/PTWNIWC3KCDCI7GA3Z7ZUZDGIXN2N6IF/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Matthew Miller

On Mon, Jun 18, 2018 at 04:48:43PM +0200, Vít Ondruch wrote:
> > https://fedoraproject.org/wiki/Fedora_Kiosk
> It does not look to be maintained ...

It seems to have  never been completed. Note the category "Spins in
Development", as well as this bit:

  The most recent blog post by the developer was Introducing the Fedora
  Kiosk Spin, April 30th 2010, at which stage it was "under development
  (as is F13)." 

In general, the wiki is not a great source of truth.

-- 
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/TVLI6UGTQ3OSMVDL4TDO2TC32TPP3JX7/

Re: F29 System Wide Change: Make BootLoaderSpec the default

On Mon, Jun 18, 2018 at 7:27 AM, Lennart Poettering
 wrote:
> On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:
>
>> The cited BLS spec is the original one, not the more thoroughly
>> discussed and thought through variant by Matthew Garrett [1] some
>> years ago.
>
> Quite frankly, as one of the authors of the original BLS spec, I can'd
> say Matthew's version was much discussed with me...

It was discussed here in devel@ extensively years ago... And there
certainly were a lot more questions than answers, which was a big part
of what Matthew Garrett was trying to address.

So this feature pointing to the original BLS inherently raises all of
those same questions and concern again.

>
> I mean, I am open to extending the spec, but we should do this bit by
> bit.
>
> Zbigniew suggested to move the spec into docbook or markdown format,
> and then accept changes via usual github PRs. If there's interest
> still in extending the spec with some of Matthew's ideas we can
> certainly look into that, but in general I'd actually prefer to reduce
> the size of the spec if possible, and drop as many bits of it as we
> can, i.e. the stuff noone implements anyway.

I'm fine with it being concise and constrained, so long as people
understand the consequences. I mainly don't want to have the feature
pointing to a spec, and then for the feature to actually implement
something else. That has been the track record so far with the bls.mod
code in Fedora's fork of GRUB. It really does us no good to have
conversations and debates about things that the feature owners have no
intention of implementing; meanwhile we totally miss having
conversations and debates on things they do intend to implement that
we don't know because they aren't in the spec.

So yeah: update the reference spec first so we aren't spinning our
wheels arguing about aspects of the spec that don't matter.

>> The cited BLS spec requires $BOOT be VFAT, are we doing that?
>
> Why would we? I mean the idea is that $BOOT can be shared among
> multiple OSes installed. Which means one really should settle on a
> format anyone can read. And VFAT certainly qualifies as that, most
> other file systems do not.

Do you mean "why wouldn't we?" Flipping over everyone's /boot to
become the ESP on VFAT is a substantial change so I'm asking the
question, yet again. This was asked a long time ago with the original
conversations on this list about BootLoaderSpec, and those questions
and answers are addressed in Matthew Garrett's derivative of the spec.

The single biggest issue with BootLoaderSpec is the part where kernels
and initramfs go on $BOOT. In 2018 the size of an existing ESP created
by Microsoft's installer is 100MB, with OEM installers creating an ESP
between 100MB and 250MB. This is too small to share, if it includes
kernels and initramfs as the spec requires. The Fedora installer
creates /boot at 1GiB, which it wants for itself. To really share it
with other distros implies a minimum size of 2G, not 500MB as the spec
says now. If an ESP already exists, that means a new partition of type
0xEA / bc13c2ff ... and that means Fedora bootloader stuff is on a
volume other than the ESP, with an existing BLS format that explicitly
doesn't allow pointing to other partitions/volumes (the Matthew
Garrett derivative addresses this). So that means a whole host of dual
boot liabilities, not just Windows but also other distros.

Also, there's no security labeling or UNIX permissions possible on
VFAT; so does the 'context=' mount option applied to the whole of this
new VFAT $BOOT sufficiently address security concerns? I think no
longer persistently mounting this volume helps security rather than
hindering it, but there's nothing in the feature proposal assessing
any of these changes.

>
>> Are we going to stop doing the diabolical (and widespread) nested
>> mount nonsense, e.g. /boot/efi? Are we getting rid of the persistent
>> mounting of these volumes in favor of mounting/unmounting dynamically
>> only by the programs that are authorized to make changes to these
>> volumes?
>
> So, in systemd we ship a generator that automatically establishes
> automount points for the ESP. It will preferably use /efi as mount
> point if it exists and is empty. If it doesn't exist or isn't
> empty it will use /boot — if that exists or is empty. If neither exist
> or are empty it won't do anything. Using an automount point for this
> has many benefits:
>
> 1) The chance that the ESP remains in a clean state is maximized, as
>the file system is unmounted whenever possible, and only mounted
>for a short time window around actual disk accesses. This is the
>behaviour you really want for something as fragile as the ESP.
>
> 2) It's compatible with current behaviour, as the path is always
>accessible under a fixed name, requiring no explicit mounting.
>
> 3) There's no need to configure any lines for the ESP in /etc/fstab
>anymore. Instead the system will d

Re: F29 System Wide Change: Make BootLoaderSpec the default

On Mon, Jun 18, 2018 at 8:40 AM, Ondřej Lysoněk  wrote:

> I also have a question regarding interoperability with distros which do
> not support BLS. Suppose I install Fedora with BLS enabled and then
> beside that install some distro which doesn't support BLS. The second
> distro will probably install its own bootloader. Will I be able to boot
> Fedora from the bootloader installed by the second OS?

BIOS: no because that distro installer will overwrite the Fedora GRUB,
and the distro installer will not support BLS drop-in scripts because
the format and parsing code are not upstream; so while it will create
a menu entry for the Fedora instance, it will not work.

UEFI: yes. grub-mkconfig + os-prober should discover the Fedora GRUB
instances, and create a chainloader boot entry to execute the Fedora
specific GRUB EFI OSLoader.

Further, since current BLS format doesn't allow pointing to other
devices or partitions, and paths are assumed to only be relative to
$BOOT, any bootloader not on $BOOT must be referenced in the
bootloader's native configuration format rather than by BLS drop in
snippet.

-- 
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/NO3WAMOROIIX3AQM5ISLIX47VNLDROCA/

Re: F29 System Wide Change: Make BootLoaderSpec the default

Also, another question about $BOOT as VFAT, is asking the kdump folks
if they're OK with the proposed change? Because right now kdump
expects to use /boot, which is historically ext4 for a long time now,
for kernel crash files. Or if they're better off writing crash files
somewhere in /var ?

When the anaconda folks were evaluating the partition size for /boot
from 500MB to 1GiB a little over a year ago, it was due to RHEL
customers running out of room with a 500MB /boot, and it's because of
the extra kdump files being written out, since I guess kdump is
enabled by default on RHEL (and maybe CentOS, not sure).

-- 
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/RZ2BNYIGC45R2V7GARI2HOC7YJHMEJKI/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Björn Persson

Ian Malone  wrote:
> 1. For example, a kiosk mode, where the home directory is wiped each
> login would be made less secure. The profile for the GUI is set at
> login, so writing .bash_profile has no effect on the GUI environment,
> but an attacker able to place files where the user has write
> permission could mask system binaries.

I agree with Zbigniew about this case: The protection fails as soon as
the user opens a terminal window.

> 2. The fact that a proof of concept cannot be provided is not a proof
> that a change you make is secure.

Nobody said it was.

And on the other hand: Somebody claiming that something is insecure, and
claiming to have a proof of concept without showing it, is not a proof
that there actually is a security problem.

> So this repeated insistence on providing a
> proof of concept before a security concern is taken seriously is
> fundamentally wrong, and I would be concerned to see it applied
> elsewhere in Fedora.

I asked for a proof of concept only because Tomasz Kłoczko claimed to
have one. I would otherwise be satisfied with a detailed description of
an attack scenario that can be analyzed to see whether it holds water.
I jumped into this debate because I couldn't stomach all the "It's
insecure because handwaving." and "It's insecure because I've said so
several times.".

Björn Persson

pgpJCfL1Me0sp.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/JO2GINHLQBTK5OBXLOFGTEH2T36BHGMR/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Björn Persson

Nico Kadel-Garcia  wrote:
> On Sat, Jun 16, 2018 at 11:38 AM, Björn Persson  wrote:
> > Nico Kadel-Garcia wrote:  
> >> On Fri, Jun 15, 2018 at 12:55 PM, Till Maas  wrote:  
> >> > 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.  
> >>
> >> No "browser" sophistication is necessary. The replacement of default
> >> system utilities by anyone who write into that private but
> >> semi-concealed $HOME/.local/bin/  
> >
> > And how did the attacker acquire write access to $HOME/.local/bin/ in
> > the first place? Do you know of a way to do that so easily that
> > appending a line to one of the shell startup files seems sophisticated
> > in comparison?
> >
> > I don't much like the proposed change to PATH, but I'm getting *really*
> > sick of all the security by handwaving that's going on in this thread.
> > Could everybody please discuss *relevant* attack scenarios, instead of
> > scenarios that begin with the attacker already having so much access
> > that the value of PATH doesn't matter?
> >
> > Björn Persson  
> 
> There are many vectors for such attacks that a sensible, locked down,
> secure, monitored environment would not experience. Popular
> vulnerabilities include:
> 
> * Stolen passwords from penetrated hosts, used for SSH connections.

So the attacker already has full control of the user account, and can
read, write and execute whatever they want. I'll assume that the
scenario you're imagining is that the attacker tries to acquire further
privileges, as passphrases that aren't stored on disk is the only thing
the attacker doesn't already have.

Passphrases can be sniffed out in various ways, for example with a
wrapper program around su, or by attaching a debugger to a running
process, but all the methods I can think of are much more sophisticated
than appending a line to one of the shell startup files.

> 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,

cat .bashrc malicious >.bashrc.pwned
touch --reference .bashrc .bashrc.pwned
mv .bashrc.pwned .bashrc

Voila! Edited file with no awareness of existing contents and no
timestamp change. That is admittedly a little more scripting than
"scp malicious victim@target:.local/bin/su", but the actual malicious
program will be much longer in either case, so I don't see how that's a
significant hurdle.

> and differs from system defaults.

Hold on a second! Are you now imagining some kind of locked-down
environment where shell startup files are regularly compared to the
system defaults and an alarm is raised if they differ? If users aren't
allowed to edit their own startup files, then wouldn't those files be
root-owned and read-only?

> Since the contents of $HOME/.local/bin are not
> defined or definable, by its very nature, it's harder to audit.

So users in this hypothetical environment aren't allowed to edit their
own startup files, but are allowed to install programs in their home
directory. Is that right?

> * Fileshares of home directories. Many environments, especially
> university environments, use NFSv3 with quite general access. Welcome
> to write access to $HOME/ !!!

Well if they have made a decision to allow any user to write in any
other user's home directory, then they're obviously not worried about
users attacking each other. I would consider that unwise, but in that
context I don't see why they would care about security aspects of the
default PATH.

> And $HOME/.local/bin is notably less
> apparent than $HOME/bin, due to the default lack of "ls" reporting of
> contents of "." prefaced directories,

As .local and .bashrc are both hidden I see no difference in that
aspect.

> and of the difficulty of leaving
> security auditing to check .bashrc, .profile, etc.

If those files are difficult to audit, then they would seem like good
places to hide malicious code, and that code would be independent of
the default PATH.

Björn Persson

pgpj6fiRwO3J2.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/44JHJ5BA2N3L6NWS7I56PMZE32TK7ZVJ/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-18 Thread Javier Martinez Canillas

On Thu, Jun 14, 2018 at 10:20 PM, Chris Murphy  wrote:
> On Thu, Jun 14, 2018 at 12:51 PM, Adam Williamson
>  wrote:
>> On Thu, 2018-06-14 at 12:06 +0200, Jan Kurik wrote:
>>> == Scope ==
>>> * Proposal owners:
>>> ** Generate BLS snippets at kernel build time and ship in the kernel 
>>> packages.
>>> ** Make kernel-install scripts to copy the BLS, kernel and initramfs
>>> images and do any architecture specific task.
>>> ** Make GRUB 2, zipl and Petitboot bootloaders to populate their boot
>>> menu entries from the information in BLS files.
>>> ** Have a grubby wrapper for backward compatbility that manipulates BLS 
>>> files.
>>> ** Modify packages that use grubby to instead install BLS fragments
>>> (memtest86+, tuned).
>>> ** Make sure this is all properly documented in release-notes, etc.
>>
>> What exactly is the plan for upgrades, here?
>
>
> "users upgrading from a previous version of Fedora will keep the old
> behaviour. "
> https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault#Upgrade.2Fcompatibility_impact
>
> I'm on the fence whether I think it's better to support two bootloader
> configurations, or compel upgrades to use the new method at some point
> and when, rather than having a community with multiple personalities
> confusion.
>
> The cited BLS spec is the original one, not the more thoroughly
> discussed and thought through variant by Matthew Garrett [1] some
> years ago.
>
> What are we getting from the cited spec? All of it? Are there
> exceptions? Where are the exceptions written?
>

The BootLoaderSpec document was cited mostly for context in case
someone was not familiar with the BLS concept. We support multiple
architectures in Fedora and not all of them use UEFI (e.g: ppc64le and
s390x), so we used the spec as a reference rather than following it
verbatim.

The value I think is in having the same file format for all supported
architectures by Fedora, so we can make tools able to parse and manage
them without needing to care about different file formats per
bootloader. It's true that we don't need BLS for that, since we could
do the same than other distros and use the grub config file for
everything (for example SuSE chain-loads zipl with grub-emu on s390x
so they can use a grub.cfg instead of a zipl.conf there). But the
advantage of BLS is that allows to have system configuration changes
as atomic operations that don't require parsing a monolithic config
file.

> 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.

> The cited BLS spec requires kernels and initramfs go on $BOOT, are we
> doing that?
>

No, the kernel and initramfs images are in /boot. By default in Fedora
we keep 3 kernel + initramfs images (installonly_limit=3 in
/etc/dnf/dnf.conf) + the rescue images (only the rescue initramfs is
~500MB). So as you said it's not realistic to have all the images in
the ESP.

> Are we going to stop doing the diabolical (and widespread) nested
> mount nonsense, e.g. /boot/efi? Are we getting rid of the persistent
> mounting of these volumes in favor of mounting/unmounting dynamically
> only by the programs that are authorized to make changes to these
> volumes?
>

That remains the same for now, the proposed change is only about
populating the boot menu entries from BLS files instead of the
bootloader configuration file.

> 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.

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/EZKEX565RVCWKIBJLWSKZWR7HJUWBZNO/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-18 Thread Peter Jones

On Mon, Jun 18, 2018 at 03:29:34PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jun 18, 2018 at 11:17:50AM -0400, Peter Jones wrote:
> > On Thu, Jun 14, 2018 at 12:40:50PM -0700, Adam Williamson wrote:
> > > On Thu, 2018-06-14 at 15:10 -0400, Matthew Miller wrote:
> > > > On Thu, Jun 14, 2018 at 11:51:33AM -0700, Adam Williamson wrote:
> > > > > > ** Have a grubby wrapper for backward compatbility that manipulates 
> > > > > > BLS files.
> > > > > 
> > > > > What exactly is the plan for upgrades, here?
> > > > 
> > > > I *assume* it's what the "grubby wrapper" is there for?
> > > 
> > > Yeah, I was hoping for more details :)
> > 
> > The grubby wrapper is actually to provide a transition plan to external
> > scripts and tools that are using grubby, but which we're not aware of.
> 
> I wonder if this providing the compat interface is worth the trouble.
> If there are those external scripts and tools, it's impossible to know
> that they still work with the replacement, unless the replacement
> implements everything *exactly* as the original, but that's pretty
> much impossible considering that the new scheme is so much different.

I think that's a valid point, but we've already written it, so I don't
think it's going to have a big practical impact to viability at this
point.  And since it doesn't need to do parse and re-write the actual
grub.cfg[0], it is relatively small and straightforward, so most changes
are either creating or removing a bls file or grub2-editenv.  Primarily
this exists to provide functionality like querying "what kernel will I
boot next?" or setting "boot $FOO next".

> So maybe it'd be both less work *and* safer, to just keep grubby as is,
> allow existing installations to continue using grubby, and switch
> all new installations to not use it at all and not even install it there?

There's literally no plan to change anything about how the grubby that
exists works aside from eventually dead-packaging it.

> F29 is not that far out actually, and I think it'd be better to devote
> available resource to the new implementation, instead of any compat
> measures.

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 :)

[0] we do run sed on zipl.conf to change default= on that platform,
because they don't have a concept like the grub environment file.

-- 
  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/B4IDUWX66K3U2E4D7XFAHSVHTYZS6M35/

Re: Packages which call install-info in scriptlets

> "PP" == Petr Pisar  writes:

PP> https://bugzilla.redhat.com/show_bug.cgi?id=1592433

I located the bug, which is that fix-info-dir needs to pass an extra
flag to install-info; otherwise install-info tries to open the info file
to figure out which entries to remove.  But of course the info file is
not there, which is why we're running fix-info-dir.

My personal desktop had some messy missing nodes in the info dir (not
related to removed scriptlets as far as I can tell) and the one liner I
posted in that ticket finally got them cleaned up.

 - J<
___
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/QEJLGZKISBSLRSXAFTHY4Y244PH5E3UH/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-18 Thread John Florian



On 2018-06-18 12:39, Chris Murphy wrote:

kdump is
enabled by default on RHEL (and maybe CentOS, not sure).


I can confirm it is on CentOS.
___
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/3PHPCFLKLLC2GVHZV6CXXJLGIOLPG4L3/

Re: F29 System Wide Change: Make BootLoaderSpec the default

On Mon, Jun 18, 2018 at 11: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:
>>> On Thu, 2018-06-14 at 12:06 +0200, Jan Kurik wrote:
 == Scope ==
 * Proposal owners:
 ** Generate BLS snippets at kernel build time and ship in the kernel 
 packages.
 ** Make kernel-install scripts to copy the BLS, kernel and initramfs
 images and do any architecture specific task.
 ** Make GRUB 2, zipl and Petitboot bootloaders to populate their boot
 menu entries from the information in BLS files.
 ** Have a grubby wrapper for backward compatbility that manipulates BLS 
 files.
 ** Modify packages that use grubby to instead install BLS fragments
 (memtest86+, tuned).
 ** Make sure this is all properly documented in release-notes, etc.
>>>
>>> What exactly is the plan for upgrades, here?
>>
>>
>> "users upgrading from a previous version of Fedora will keep the old
>> behaviour. "
>> https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault#Upgrade.2Fcompatibility_impact
>>
>> I'm on the fence whether I think it's better to support two bootloader
>> configurations, or compel upgrades to use the new method at some point
>> and when, rather than having a community with multiple personalities
>> confusion.
>>
>> The cited BLS spec is the original one, not the more thoroughly
>> discussed and thought through variant by Matthew Garrett [1] some
>> years ago.
>>
>> What are we getting from the cited spec? All of it? Are there
>> exceptions? Where are the exceptions written?
>>
>
> The BootLoaderSpec document was cited mostly for context in case
> someone was not familiar with the BLS concept. We support multiple
> architectures in Fedora and not all of them use UEFI (e.g: ppc64le and
> s390x), so we used the spec as a reference rather than following it
> verbatim.
>
> The value I think is in having the same file format for all supported
> architectures by Fedora, so we can make tools able to parse and manage
> them without needing to care about different file formats per
> bootloader. It's true that we don't need BLS for that, since we could
> do the same than other distros and use the grub config file for
> everything (for example SuSE chain-loads zipl with grub-emu on s390x
> so they can use a grub.cfg instead of a zipl.conf there). But the
> advantage of BLS is that allows to have system configuration changes
> as atomic operations that don't require parsing a monolithic config
> file.
>
>> 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.
>
>> The cited BLS spec requires kernels and initramfs go on $BOOT, are we
>> doing that?
>>
>
> No, the kernel and initramfs images are in /boot. By default in Fedora
> we keep 3 kernel + initramfs images (installonly_limit=3 in
> /etc/dnf/dnf.conf) + the rescue images (only the rescue initramfs is
> ~500MB). So as you said it's not realistic to have all the images in
> the ESP.
>
>> Are we going to stop doing the diabolical (and widespread) nested
>> mount nonsense, e.g. /boot/efi? Are we getting rid of the persistent
>> mounting of these volumes in favor of mounting/unmounting dynamically
>> only by the programs that are authorized to make changes to these
>> volumes?
>>
>
> That remains the same for now, the proposed change is only about
> populating the boot menu entries from BLS files instead of the
> bootloader configuration file.
>
>> 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.


Thanks for the reply.

I think the proposal title is misleading. The BLS file format is,
depending on one's point of view, 5% of the spec. A bulk of the
proposal isn't going to follow the spec at all. And even with regards
to the file format, you're not following the spec which mandates all
paths relative to $BOOT, which clearly isn't going to be the case. And
that makes the BLS file format you're implementing, more close to GRUB
legacy, and the Matthew Garrett BLS format derivative, than the
original BLS spec format.

I think the feature proposal should be rename: 'Make using
BootLoaderSpec style file format the default'

The proposal doesn't follow the BLS spec in some of the most critical
ways necessary to get it adopted by upstreams and other distros.

My summary of the change for most users (x86_64)
- /etc/grub.d/10_linux will no longer contain Fedora entries, each
menu entry will be a BLS format drop in script instead
- grub.cfg still is responsible for multibooting Windows and other
distros via /etc/grub.d/30_os-prober
- users will no longer modify /etc/default/grub, they will duplicate
(?) and modify BLS scr

Re: F29 System Wide Change: Make BootLoaderSpec the default

On Mon, Jun 18, 2018 at 12:14 PM, Chris Murphy  wrote:

> My summary of the change for most users (x86_64)

> - users will no longer modify /etc/default/grub, they will duplicate
> (?) and modify BLS scripts directly if they need to make permanent
> changes to menu entries

I assumed wrong. I'm seeing the kernel parameters have been moved to
the grubenv. That is the single most significant user facing change.

Also the path to $BOOT is defined in grub.cfg, so the BLS format being
used is consistent with the original BLS spec's format, in that paths
are relative to $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/TAIPRFXCMFJ24U2MKTWQWR6GP6YZIPC7/

Re: upcoming systemd-239 release — call for testing

> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:

ZJ> rpm does not allow reading that file from the tarball, because it
ZJ> wants it to be available for %include when the spec file is parsed.
ZJ> That's why I put the in git directly.

This one of several reasons why using %include in a Fedora specfile is
such a terrible idea.  Please just don't do it.  It renders the spec
unusable unless you have a git checkout or the srpm, and thus makes a
bunch of things that you could do from, say, the nightly specfile
tarball (https://src.fedoraproject.org/repo/rpm-specs-latest.tar.xz)
rather more difficult.

 - J<
___
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/XPU4UMEA32XJQSWWPTT2X55YPHN65BBA/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-18 Thread Peter Jones

On Mon, Jun 18, 2018 at 12:14:31PM -0600, Chris Murphy wrote:
> Thanks for the reply.
> 
> I think the proposal title is misleading. The BLS file format is,
> depending on one's point of view, 5% of the spec. A bulk of the
> proposal isn't going to follow the spec at all. And even with regards
> to the file format, you're not following the spec which mandates all
> paths relative to $BOOT, which clearly isn't going to be the case. And
> that makes the BLS file format you're implementing, more close to GRUB
> legacy, and the Matthew Garrett BLS format derivative, than the
> original BLS spec format.
> 
> I think the feature proposal should be rename: 'Make using
> BootLoaderSpec style file format the default'

I've updated the page with a bunch of changes to try and help with this
confusion, including changing the top heading and adding a section about
the differences between the various specs and what's currently
implemented and a section about what our boot entry config files look
like, as well as notes about $kernelopts and $grub_users.

> The proposal doesn't follow the BLS spec in some of the most critical
> ways necessary to get it adopted by upstreams and other distros.
> 
> My summary of the change for most users (x86_64)
> - /etc/grub.d/10_linux will no longer contain Fedora entries, each
> menu entry will be a BLS format drop in script instead

Er, will no longer *generate* them, but yes.

> - grub.cfg still is responsible for multibooting Windows and other
> distros via /etc/grub.d/30_os-prober

Right, though this continues to become less and less relevant with
things like BitLocker storing keys in TPM.

> - users will no longer modify /etc/default/grub, they will duplicate
> (?) and modify BLS scripts directly if they need to make permanent
> changes to menu entries

As you mention in your next post, if you want to change the command line
globally, we're getting it from grubenv, which mkconfig is setting from
/etc/default/grub's value.

> - users will no longer need to run grub2-mkconfig, unless the grub.cfg
> is accidentally missing or malformed

Right.

> - users on BIOS systems who install another distro after Fedora, will
> need to inform the distro's installer to not overwrite the Fedora
> bootloader, or the user will need to reinstall the Fedora bootloader;
> until such time as distro bootloaders support the BLS format

Or they'll need to chainload to it, from a different disk for example.

-- 
  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/U6FQJYUYH7BCZ5TQC6RWFNANMR2UFBHB/

Re: upcoming systemd-239 release — call for testing

On Mon, Jun 18, 2018 at 01:34:53PM -0500, Jason L Tibbitts III wrote:
> > "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:
> 
> ZJ> rpm does not allow reading that file from the tarball, because it
> ZJ> wants it to be available for %include when the spec file is parsed.
> ZJ> That's why I put the in git directly.
> 
> This one of several reasons why using %include in a Fedora specfile is
> such a terrible idea.  Please just don't do it.  It renders the spec
> unusable unless you have a git checkout or the srpm, and thus makes a
> bunch of things that you could do from, say, the nightly specfile
> tarball (https://src.fedoraproject.org/repo/rpm-specs-latest.tar.xz)
> rather more difficult.

It's either %include or a fairly big copy&paste. The first solution is
awkward, and the second one is ... awkward. But yeah, maybe we should
bite the bullet and do the copy&paste. A bit sad.

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/SA6HF2ZI4VVZJ7X766TCZLM2RKYV6WUH/

Re: upcoming systemd-239 release — call for testing

> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:

ZJ> It's either %include or a fairly big copy&paste. The first solution
ZJ> is awkward, and the second one is ... awkward. But yeah, maybe we
ZJ> should bite the bullet and do the copy&paste. A bit sad.

It shouldn't be that bad.  The body of the scriptlet shouldn't be large.
If it is, then put it in its own, install that, and have the scriptlet
call it.

I went to look at why the scriptlets are so large, but of course I'm
looking at the spec tarball and so all I can see is %include %{SOURCE1}.
Oh, well.

 - J<
___
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/U33JU36MBW5Q5PSHATSGSXLB6TH4OKWZ/

Re: upcoming systemd-239 release — call for testing

On Mon, Jun 18, 2018 at 03:28:17PM -0500, Jason L Tibbitts III wrote:
> > "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:
> 
> ZJ> It's either %include or a fairly big copy&paste. The first solution
> ZJ> is awkward, and the second one is ... awkward. But yeah, maybe we
> ZJ> should bite the bullet and do the copy&paste. A bit sad.
> 
> It shouldn't be that bad.  The body of the scriptlet shouldn't be large.
> If it is, then put it in its own, install that, and have the scriptlet
> call it.

That's not an attractive option, because there's so many of them.
Also, the scriptlets are (were, it's a longer story) in lua, executed
inline. Moving that out to a separate file would break that.
See https://github.com/systemd/systemd/blob/master/src/core/triggers.systemd.in.

> I went to look at why the scriptlets are so large, but of course I'm
> looking at the spec tarball and so all I can see is %include %{SOURCE1}.
> Oh, well.

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/VIOG5TPLK6V3ITDNJLAPGJJDGPZJBLEZ/

Re: upcoming systemd-239 release — call for testing

> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:

ZJ> That's not an attractive option, because there's so many of them.

Ah, so the issue is merely the quantity of scripts.  I did check out the
package from git and it doesn't seem all that bad; most of what's there
is (sort of excessively verbose) comments and without them you just have
54 lines.  In lua it would be a bit more verbose, certainly, though
interestingly most of what's there is boilerplate and makes me wonder if
most of that could be generated by a macro.

Unfortunately rpm just isn't optimized for the number of things the
systemd package needs to do.  Any solution is probably going to be a bit
awkward.

 - J<
___
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/E3UUGJ5T3WAQBG3RQEAOOFLLAZL5RHXA/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-18 Thread R P Herrold

On Mon, 18 Jun 2018, Lennart Poettering wrote:

> On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:
> 
> > The cited BLS spec is the original one, [1]

... later: L.P.:
> [reduce] the size of the spec if possible, and drop as many 
> bits of it as we can, i.e. the stuff noone implements 
> anyway.
> 
> > The cited BLS spec requires $BOOT be VFAT, are we doing that?

Will cgroup and SElinux protections work in VFAT ?

 
> Why would we? I mean the idea is that $BOOT can be shared among
> multiple OSes installed. Which means one really should settle on a

I see a lot of need in [1] for re-partitioning and optionally 
adding a /boot partition where none was specified, to make 
this work

The move toward containers includes getting away from more 
than a single partition (and so, a separate /boot partition, 
as mostly irrelavant).  Getting rid of a separate /boot 
partition is a win, as it  removes the need for a separate 
mountpoint in /etc/fstab for a '/boot/'. partition, and all 
the gyrations as to partitioning in [1]

N.B.: This is a 'Good Thing' as one does not get 'out of sync 
with each other between 'root of filesystem', and /boot/ when 
they are all in a single filesystem


> So, in systemd we ship a generator that automatically establishes
> automount points for the ESP. It will preferably use /efi as mount
> point if it exists and is empty. If it doesn't exist or isn't
> empty it will use /boot — if that exists or is empty. If neither exist
> or are empty it won't do anything

I think this last is a negative: 
>  ... it won't do anything

and I submit that the proper course, when no /boot partition 
is seen, is to properly mount the root of filesystem, and do 
a:
 mkdir /boot
and then continue on


To wrestle with all the failure modes, I see a lot of 
fall-through logic, and a lot more complexity, including 
re-partitioning by the boot loader on a device it may not have 
RW rights at the partition table level -- yikes, as to an 
added point of faiure -- outlined in the initial proposa [1]l, 
but not implied in Matthew Garrett's [2]

But for the fact that that kernel updates do not 'just apply' 
with the current grubby / dracut regime, the approach of a 
/boot/ directory (but not separate partition) works in 
production just fine and has for over a decade [3] 

I suspect that moving to such as an option, and adding a 
systemd umount RW / remount RO of 'root of filesystem' on the 
way to a shutdown, would ameriorate if not totally remedy [4] 
and [5] as well.  Just the remount RO by systemd will cause 
the needed 'sync' actions on the way down would solve: [6] and 
its Fedora twin: [7]

If a '/boot/' partition is absent, simply creating a /boot/ 
directory at the root of the file system does away with the 
need for many of the gyrations of [1].

-- Russ herrold

[1] https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/

[2] https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/

[3] https://bugzilla.redhat.com/show_bug.cgi?id=1498169

[4] https://bugzilla.redhat.com/show_bug.cgi?id=1533620

[5] https://bugzilla.redhat.com/show_bug.cgi?id=1569970

[6] https://bugzilla.redhat.com/show_bug.cgi?id=1464611

[7] https://bugzilla.redhat.com/show_bug.cgi?id=1466036
___
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/QGECPUQBDZFIWDTYZRBJGIBHOVAIHALZ/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-18 Thread Andrew Lutomirski

> 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.

>
>
>> 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.

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.

All that being said, $BOOT should not use security context xattrs —
getting that to work right across distros is probably impossible.

[0] I use mdadm a lot, and I never use 0.9 or 1.0. It’s too fragile.
___
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/JURU4F7L5CLTXWINANC2WVTBTRMTE76T/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-18 Thread Tom Hughes


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.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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/O36DGKINVAYYLHQGDA4GBIZ5JJYS7KBP/

[Fedocal] Reminder meeting : Modularity Office Hours

2018-06-18 Thread nils

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2018-06-19 from 10:00:00 to 11:00:00 US/Eastern
   At fedora-modular...@chat.freenode.net

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): 
#fedora-modularity on [FreeNode](https://freenode.net)


Source: https://apps.fedoraproject.org/calendar/meeting/5910/

___
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/LIKXVCUX7NTGQSWWNVVSEAV45YUPXUFE/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-18 Thread Javier Martinez Canillas

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.

[0]: 
https://src.fedoraproject.org/rpms/grub2/c/db7cf3a089075af0f4a8b955af508aea3893465a

> Tom
>

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/UGUSZIBOLV4XUZPKZ3ZTYZ2HJO36KPES/

Re: F29 System Wide Change: Make BootLoaderSpec the default

On Mon, Jun 18, 2018 at 3:42 PM, Andrew Lutomirski  wrote:
>> On Jun 18, 2018, at 10:02 AM, Javier Martinez Canillas  
>> wrote:

>> 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.

I don't like it either but I'm trying to keep an open mind. What I
recall from the conversations years ago with the mgj59 variant, it's a
lot easier to poke holes in any attempt to standardize bootloading,
than to standardize bootloading. But if no one is willing to give any
ground anywhere, it's way too easy to stop progress.

The proposed change doesn't really fix any of the user facing
problems, it just gets us away from depending on grubby and
grub-mkconfig (we never really depended on grub-mkconfig, the
installer uses it as a one shot). So in the most narrow sense, the
change succeeds at doing the only thing it's intending to do. But
yeah, I lament that we're not being more aggressive while we have the
chance to fix past oversights.

>
>>
>>
>>> 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.

Well as it turns out all the file systems are fragile as far as the
bootloader is concerned :-P We've got bugs where the bootloader can't
read needed files, because part of the commit is still in the journal
rather than fully flushed out to file system metadata. So no matter
what you can break a set up...

> 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.

Getting journal support in the bootloader isn't going to happen. I've
already talked to the various fs upstreams about it.

> 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. But *le sigh* we have fwupd which wants /boot/efi mounted

I use 'umask=0077,shortname=winnt,nofail,noauto,x-systemd.automount'
in fstab for /boot/efi and yet every boot:

Jun 17 14:07:06 f28h.local systemd[1]: boot-efi.automount: Got
automount request for /boot/efi, triggered by 2268 (fwupd)

So add that to the list of packages that need an ESP syncing daemon if
they don't want to be responsible for dynamically mounting and
umounting the ESP.

> All that being said, $BOOT should not use security context xattrs —
> getting that to work right across distros is probably impossible.

It's a good point. I'm not really sure  how to prevent conflicts if
there is to be a truly shared $BOOT unless it is a file system that
will reject xattrs.

-- 
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/L4K3FPKNIVFQSLKCRZJ4NGXFTITKZKWZ/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-18 Thread Tom Hughes

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.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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/ABOGNY2QEU57N6NWGQZ47BPN56JC3JYT/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-18 Thread Andrew Lutomirski

> On Jun 18, 2018, at 3:54 PM, Chris Murphy  wrote:
>
> On Mon, Jun 18, 2018 at 3:42 PM, Andrew Lutomirski  wrote:
>>> On Jun 18, 2018, at 10:02 AM, Javier Martinez Canillas 
>>>  wrote:
>
>>> 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.
>
> I don't like it either but I'm trying to keep an open mind. What I
> recall from the conversations years ago with the mgj59 variant, it's a
> lot easier to poke holes in any attempt to standardize bootloading,
> than to standardize bootloading. But if no one is willing to give any
> ground anywhere, it's way too easy to stop progress.
>
> The proposed change doesn't really fix any of the user facing
> problems, it just gets us away from depending on grubby and
> grub-mkconfig (we never really depended on grub-mkconfig, the
> installer uses it as a one shot). So in the most narrow sense, the
> change succeeds at doing the only thing it's intending to do. But
> yeah, I lament that we're not being more aggressive while we have the
> chance to fix past oversights.
>
>

And that's fine, as long as it's not done in a way that makes it
harder to improve in the future.

>>>
 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.
>
> Well as it turns out all the file systems are fragile as far as the
> bootloader is concerned :-P We've got bugs where the bootloader can't
> read needed files, because part of the commit is still in the journal
> rather than fully flushed out to file system metadata. So no matter
> what you can break a set up...
>

...

>
> Getting journal support in the bootloader isn't going to happen. I've
> already talked to the various fs upstreams about it.
>

Why are you talking to the fs upstreams?  The problem is a bug in
GRUB, full stop. All this freeze crap that Fedora does is just
papering over the bug.  IMO the right thing to do is to get *GRUB*
upstream to have a fully functional implementation of *one*
widely-supported fs.  Hmm, GRUB supports F2FS, and F2FS is
log-structured, right?  So I don't see how GRUB could fail to read a
dirty filesystem correctly even if it wanted to.

Or someone could design a very simple, highly reliable, filesystem
designed to make it easy to do atomic-enough updates and to read
reliably.  Think VFAT-like but with a full atomic swap of all FS
metadata.  Or a dead-simple log-structured FS.  /me ducks.

Seriously, though, F2FS might be a fantastic choice for this purpose.

>
>> 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. But *le sigh* we have fwupd which wants /boot/efi mounted
>
> I use 'umask=0077,shortname=winnt,nofail,noauto,x-systemd.automount'
> in fstab for /boot/efi and yet every boot:
>
> Jun 17 14:07:06 f28h.local systemd[1]: boot-efi.automount: Got
> automount request for /boot/efi, triggered by 2268 (fwupd)
>
> So add that to the list of packages that need an ESP syncing daemon if
> they don't want to be responsible for dynamically mounting and
> umounting the ESP.

I disagree.  fwupd doesn't need any ESP syncing.  In the very worst
case, fwupd sticks a capsule in the ESP from which we booted, then
that disk dies, and we don't apply the capsule.  No harm done.

I really think the correct approach here is to have an ESP on each
potentially bootable disk.  Each ESP will independently contain the
code to handle BootLoaderSpec entries on a *different* partition.  The
only time we need to modify all the ESP copies is when we upgrade GRUB
or upgrade GRUB's configuration.  We do *not* need to propagate
capsules or any other similar objects.  And we should not even try to
impose a requirement that the filesystems be bitwise identical.
They're *copies*, not RAID.

>
>
>> All that being said, $BOOT should not use security context xattrs —
>> getting that to work right across distros is probably impossible.
>
>
> It's a good point. I'm not really sure  how to prevent conflicts if
> there is to be a truly shared $BOOT unless it is a file system that
> will reject xattrs.
>

Mount with noxattr?

--Andy
___
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.h

Re: F29 System Wide Change: Make BootLoaderSpec the default