Re: ZFS feature flags

2019-10-23 Thread Richard Laager
On 10/19/19 4:43 AM, Colin Watson wrote:
> I don't have much to say about most of this, but noticed this bit:
> 
> On Thu, Oct 17, 2019 at 09:48:42PM -0500, Richard Laager wrote:
>> The same implementation could (and if I have my way, will) be used to
>> provide a features=grub mask. This would be used for the boot pool
>> (bpool) to limit it to the features supported by GRUB. This would avoid
>> the dangerous message in "zpool status" which tells you to run "zpool
>> upgrade" on your bpool which would then break booting from it.
> 
> Isn't that a dubious and confusing way to spell it?

I'm certainly open to a different name.

> After all, like any
> other ZFS implementation, GRUB's ZFS implementation has gained features
> over time, and it wouldn't surprise me if it continued to do so.  It
> sounds like you'd need a set of versioned features for this as well as
> for features=portable; but it's not clear how the decision of when to
> promote a feature set to the unversioned level would be made,
> particularly given GRUB's rather slow and unpredictable release cycle
> and the widespread practice of backporting features by distribution
> maintainers.

The proposal, as I understand it, is that the unversioned
features=portable is defined as the set of features common to all the
latest releases of specific "tier 1" ZFS platforms: FreeBSD,
illumos-gate*, Ubuntu LTS, and ZoL**. A feature is promoted into the
unversioned features=portable when it is available in all of those
platforms' latest releases. As new platform releases push out older
releases, the set of common features expands and the definition of
features=portable can be updated.

* illumos-gate, which I think doesn't have releases, was going to use a
time-based cutoff.

** In practice, unless Ubuntu backports something from git master or
writes their own ZFS feature, Ubuntu LTS will always be a subset of the
latest ZoL release. Thus, Ubuntu LTS will be the limiting factor for the
common set, not the latest ZoL release.

The versioned features=portable- are simply features=portable frozen
in time on January 1 of . The versioned ones are not driving
anything design-wise, so they are mostly irrelevant for this discussion.
If people also want versioned grub-, that's trivial to do.

I think there are two approaches to take for features=grub. Originally,
I was thinking that features=grub would be the set of features that are
supported by GRUB on the current system. This solves the `zpool status`
/ `zpool upgrade` issues for the boot pool, which is the main goal.

However, that definition could hamper dual-booting scenarios, so
features=grub should probably be similar to features=portable. It should
be the set of features common to all the latest releases of specific
"tier 1" ZFS platforms that use GRUB (specifically GRUB 2, not GRUB
Legacy) as their bootloader. I don't think that FreeBSD uses GRUB, and
neither illumos nor ZoL are whole distros, so in practice this is just
Ubuntu LTS at the moment. It may be desirable to expand this to include
other distros where root-on-ZFS is a thing, like Arch and Gentoo. In
other words, features=grub should be the features supported by GRUB in
the latest release of whichever distros people might realistically want
to dual-boot off the bpool.

Whether the feature arrives in Ubuntu 20.04's GRUB by GRUB release or
distro backport is irrelevant. The only thing that matters is which
features are supported.

An additional subtlety is that GRUB opens the pool read-only, so every
read-only feature is "supported" from a GRUB perspective. So what GRUB
"supports" on, for example, Ubuntu 20.04 is the union of the
features-for-write actually supported by GRUB in Ubuntu 20.04, plus all
read-only compatible features supported by the kernel ZFS implementation
on Ubuntu 20.04. (Dependencies have to kept in mind here. If feature X
is read-only compatible but depends on feature Y which is not read-only
compatible, and feature Y is not supported by GRUB, then feature X is
not supported by GRUB.)

-- 
Richard

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Crash in Qt 5.12.2

2019-10-23 Thread Alex Murray

On Wed, 2019-10-23 at 21:51:27 +1030, Robert Loehning wrote:

> Am 23.10.19 um 09:29 schrieb Alex Murray:
>> 
>> On Wed, 2019-10-23 at 17:32:58 +1030, Robert Loehning wrote:
>> 
>>> Am 22.10.19 um 18:41 schrieb Dmitry Shachnev:
 Hi again Robert,

 On Fri, Oct 18, 2019 at 02:14:01PM +, Robert Loehning wrote:
> Hi,
>
> every application based on Qt will crash when opening a crafted plain
> text file. Could you please add the patch below to your builds to fix 
> this?
>
> Thank you and have a nice weekend.

 Let me forward you a question I got on the bug:

 https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1848784/comments/1

   This would appear to have security implications since I imagine if an 
 email
   were sent to a KMail recipient which was crafted in this same way it 
 would
   crash KMail? If this is likely true a CVE should be requested from MITRE 
 via
   https://cveform.mitre.org/ so that other distros etc can ensure they ship
   this patch too.

 What do you think about this?

 --
 Dmitry Shachnev

>>>
>>> Hi Dmitry,
>>>
>>> this is most probably right. I expect that it's possible to crash KMail
>>> in that way. With Quassel, it was already used ITW.
>>>
>>> I don't think I'm authorized to send you such a crafted file, but if you
>>> look closely at the test for the attached fix, you can probably figure
>>> it out yourself.
>>>
>>> I'm not aware of an existing CVE for this issue, though.
>> 
>> FYI - I have just submitted a CVE application for this to MITRE so that
>> all distros can be notified of, and backport the fix as appropriate.
>
> Wonderful! Thank you so much!

MITRE have assigned CVE-2019-18281 for this issue.

>
> Cheers,
> Robert


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Crash in Qt 5.12.2

2019-10-23 Thread Alex Murray

On Wed, 2019-10-23 at 17:32:58 +1030, Robert Loehning wrote:

> Am 22.10.19 um 18:41 schrieb Dmitry Shachnev:
>> Hi again Robert,
>> 
>> On Fri, Oct 18, 2019 at 02:14:01PM +, Robert Loehning wrote:
>>> Hi,
>>>
>>> every application based on Qt will crash when opening a crafted plain
>>> text file. Could you please add the patch below to your builds to fix this?
>>>
>>> Thank you and have a nice weekend.
>> 
>> Let me forward you a question I got on the bug:
>> 
>> https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1848784/comments/1
>> 
>>   This would appear to have security implications since I imagine if an email
>>   were sent to a KMail recipient which was crafted in this same way it would
>>   crash KMail? If this is likely true a CVE should be requested from MITRE 
>> via
>>   https://cveform.mitre.org/ so that other distros etc can ensure they ship
>>   this patch too.
>> 
>> What do you think about this?
>> 
>> --
>> Dmitry Shachnev
>> 
>
> Hi Dmitry,
>
> this is most probably right. I expect that it's possible to crash KMail
> in that way. With Quassel, it was already used ITW.
>
> I don't think I'm authorized to send you such a crafted file, but if you
> look closely at the test for the attached fix, you can probably figure
> it out yourself.
>
> I'm not aware of an existing CVE for this issue, though.

FYI - I have just submitted a CVE application for this to MITRE so that
all distros can be notified of, and backport the fix as appropriate.

>
> Cheers,
> Robert


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss