Mailing List Archive

Soliciting feedback for the GLSA-2 format
Now that we've been growing a bit in numbers and have managed to get the
GLSA circulation back on track, it is time to finally talk about the new
GLSA format that has been planned for quite a while.
The main goal of the new format is to support slots which is a feature
especially glsa-check users will welcome. [1]
Besides, it has become clear that filling in information in the level of
detail the current format provides takes too much time while drafting
advisories.

Tobias and I took a bit of time today to combine all desired changes
into a new sample document:

http://a3li.li/~alex/gentoo/security/glsa-2-example.xml

Quick outline of the most important changes:

- Synopsis removed: The title provides a quick overview of the issues,
while the new shorter description provides details, yet briefly as well.
People requiring even more information can use the linked CVE entries,
bugs, and other references.

- Product and GLSA type removed: There are only 'ebuild' type GLSAs
issued, the other types are no longer needed. Product was linked to that.

- Packages section reworked: While adding Slot support we tried to get a
new, simple, range-based scheme for marking vulnerable versions. The
flexibility the range operators offered before was hardly ever used
(mostly just to work around the lacking Slot support). We'd especially
like feedback in this area, I fear we might be missing some
functionality here. Quick explanation:
<package name="dev-lang/python">
<vulnerable slot="3.2" fixed="3.2.9"/>
<vulnerable slot="3.3" asof="3.3.0" fixed="3.3.1"/>
<vulnerable slot="3.3" asof="3.3.3" fixed="3.3.5"/>
<vulnerable slot="0" fixed="6.3"/>
</package>
<package name="dev-lang/python" arch="hppa">
<vulnerable/>
</package>

Reads as follows:
On hppa, there is no fixed version.
On all other arches, python in slot 3.2 is fixed in >=3.2.9, affected
for anything less, in the 3.3 slot, [.3.3.0; 3.3.1[. and [.3.3.3; 3.3.5[.
are affected, for the 0 slot, anything <6.3 is affected.

- Human-readable texts reworked: Background + Description + Resolution
instead of (Synopsis) + Background + Description + Impact + Resolution.

- References reworked: Bugs moved into that tag, CVEs get their own tag
without a link that could break, other references go as <url>

- Metadata: Mostly leftovers from GLSAMaker v1 removed; We now list the
author as well as people reviewing a draft and signing off on it with a
proper name. Dates are in a standardized format.

If there are any other questions, we'll do our best to answer them.
Other than that, we'd appreciate any feedback.


[1] Especially after today most glsa-check users got another set of
false-positives from a faulty python GLSA that could have used it.

--
Alex Legler <a3li@gentoo.org>
Gentoo Security/Ruby/Infrastructure
Re: Soliciting feedback for the GLSA-2 format [ In reply to ]
On 08.01.2014 02:14, Alex Legler wrote:
> Reads as follows:
> On hppa, there is no fixed version.
> On all other arches, python in slot 3.2 is fixed in >=3.2.9, affected
> for anything less, in the 3.3 slot, [.3.3.0; 3.3.1[. and [.3.3.3; 3.3.5[.
> are affected, for the 0 slot, anything <6.3 is affected.

I fear this less commonly used interval notation may not be known to
some people. See [1] for an explanation.

Further notes on that:

- If no slot attribute is given, it defaults to slot 0 (same as
Portage).
- Our existing (old) scheme employs a whitelist approach: We usually
only have one <vulnerable> entry and then list the <unaffected> versions
explicitly. Our new approach works more like a whitelist; if an entry
without the asof attribute (and possibly without a slot attribute) is
given, we sort of get the old behaviour.

> - Human-readable texts reworked: Background + Description + Resolution
> instead of (Synopsis) + Background + Description + Impact + Resolution.

The workaround field is also gone now. We never used it anyway, and it's
just another human-readable field that could as well be merged with the
resolution field.


[1] http://en.wikipedia.org/wiki/Interval_(mathematics)
Re: Soliciting feedback for the GLSA-2 format [ In reply to ]
On 08.01.2014 02:40, Tobias Heinlein wrote:
> Our new approach works more like a whitelist;

"more like a blacklist", that is.
Re: Soliciting feedback for the GLSA-2 format [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/07/2014 08:42 PM, Tobias Heinlein wrote:
> On 08.01.2014 02:40, Tobias Heinlein wrote:
>> Our new approach works more like a whitelist;
>
> "more like a blacklist", that is.
>
>
I kind of would like the workaround field to remain (but perhaps be
optional) since I have seen a few vulns that actually did have
functional workarounds. Not absolutely necessary.

Chris Reffett
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlLN6G9fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1T9+gCfUCZn/E5AZGvuX1od+rvJPsdH
ZR0AnR/sb6yPZpmiolxM0/HVQmnk3lng
=dm0O
-----END PGP SIGNATURE-----
Re: Soliciting feedback for the GLSA-2 format [ In reply to ]
Forwarding from a private reply.

>> Now that we've been growing a bit in numbers and have managed to get the
>> GLSA circulation back on track, it is time to finally talk about the new
>> GLSA format that has been planned for quite a while.
>
> Yay, very exciting!
>
>> - Packages section reworked: While adding Slot support we tried to get a
>> new, simple, range-based scheme for marking vulnerable versions. The
>> flexibility the range operators offered before was hardly ever used
>> (mostly just to work around the lacking Slot support). We'd especially
>> like feedback in this area, I fear we might be missing some
>> functionality here. Quick explanation:
>> <package name="dev-lang/python">
>> <vulnerable slot="3.2" fixed="3.2.9"/>
>> <vulnerable slot="3.3" asof="3.3.0" fixed="3.3.1"/>
>> <vulnerable slot="3.3" asof="3.3.3" fixed="3.3.5"/>
>> <vulnerable slot="0" fixed="6.3"/>
>> </package>
>> <package name="dev-lang/python" arch="hppa">
>> <vulnerable/>
>> </package>
>>
>> Reads as follows:
>> On hppa, there is no fixed version.
>> On all other arches, python in slot 3.2 is fixed in >=3.2.9, affected
>> for anything less, in the 3.3 slot, [3.3.0; 3.3.1[ and [3.3.3; 3.3.5[
>> are affected, for the 0 slot, anything <6.3 is affected.
>
> Some thoughts:
>
> 1. It'd be great to see some pseudo-code algorithm for processing this.
>

If anyone finds the time, I'd rather have a verbatim definition and a
working reference implementation.

> 2. I'd prefer to avoid embedding too much knowledge of how dependencies
> work into GLSA (which is then subject to change as PMS changes). One
> crazy example would be vulnerability existing only when a certain USE
> flag is enabled, which currently cannot be expressed in GLSA and I don't
> know if it'd be useful/desirable (certainly not if GLSA syntax would
> need to change IMHO).

There are no plans to add any more dependency features.

>
> 3. Please consider just using portage atoms syntax, e.g.
>
> <vulnerable package="<dev-lang/python-3.2.9:3.2" />
> <vulnerable package="<dev-lang/python-3.3.5:3.3" />
> <vulnerable package="<dev-lang/python-6.3:0" />
> <vulnerable package="dev-lang/python" arch="hppa" />
>
> Then the set of vulnerable packages is a union of all matching atoms.
>
> Note that the above cannot encode that 3.3.1 is not vulnerable. I
> consider that an OK compromise for more simplicity.

1. This combines multiple attributes (package, version, slot,
comparator) into one field. That's something we've explicitly tried to
avoid when putting together an XML format.

2. We need exclusion of previous versions. Example: Package has no
slots, 1.x versions are unaffected, 2.x is affected and fixed in 2.1.
The 1.x versions need to be declarable as not vulnerable.

>
>> - Human-readable texts reworked: Background + Description + Resolution
>> instead of (Synopsis) + Background + Description + Impact + Resolution.
>>
>> - References reworked: Bugs moved into that tag, CVEs get their own tag
>> without a link that could break, other references go as <url>
>
> These are all awesome, glad to see that.
>
> Why not go further and even remove background? That can be taken from
> package description.

We thought about that. The problem is that ebuild descriptions are
non-uniform. That looks bad.

>
> I'm also thinking about title. Since it's going to contain package
> name(s) and "multiple vulnerabilities" most of the time, yet needs to be
> manually edited by a developer, it allows for inconsistencies and just
> makes editing/drafting harder (one needs to think what to put there).
> Why not just drop it from the XML and use list of packages and date for
> display or something similar?

There are templates for the title in our drafting software.
I feel like there's no gain in removing this.

>
>> - Metadata: Mostly leftovers from GLSAMaker v1 removed; We now list the
>> author as well as people reviewing a draft and signing off on it with a
>> proper name. Dates are in a standardized format.
>
> All sounds good.
>
> Paweł
>
>
Re: Soliciting feedback for the GLSA-2 format [ In reply to ]
On 09.01.2014 01:08, Chris Reffett wrote:
> On 01/07/2014 08:42 PM, Tobias Heinlein wrote:
>> On 08.01.2014 02:40, Tobias Heinlein wrote:
>>> Our new approach works more like a whitelist;
>
>> "more like a blacklist", that is.
>
>
> I kind of would like the workaround field to remain (but perhaps be
> optional) since I have seen a few vulns that actually did have
> functional workarounds. Not absolutely necessary.
>

Does it need to have its own field, can't it be part of the (temporary)
resolution?

> Chris Reffett
>

--
Alex Legler <a3li@gentoo.org>
Gentoo Security/Ruby/Infrastructure
Re: Soliciting feedback for the GLSA-2 format [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/09/2014 10:42 AM, Alex Legler wrote:
> On 09.01.2014 01:08, Chris Reffett wrote:
>> On 01/07/2014 08:42 PM, Tobias Heinlein wrote:
>>> On 08.01.2014 02:40, Tobias Heinlein wrote:
>>>> Our new approach works more like a whitelist;
>>
>>> "more like a blacklist", that is.
>>
>>
>> I kind of would like the workaround field to remain (but perhaps
>> be optional) since I have seen a few vulns that actually did
>> have functional workarounds. Not absolutely necessary.
>>
>
> Does it need to have its own field, can't it be part of the
> (temporary) resolution?
>
>> Chris Reffett
>>
>
I guess it would work as part of the resolution, perhaps we could have
a template for "A temporary fix for this issue is also available: ..."
for that. Didn't think of that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlLOw+RfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1SKEgCeLuRlJxXSQFNDpVH23uXlrBEQ
tFcAnRLbKzzL5KSWHpfu4LX0SxJA0jWA
=92Vy
-----END PGP SIGNATURE-----
Re: Soliciting feedback for the GLSA-2 format [ In reply to ]
Alex,

is this what the users will see as generated from XML?

Yury German
E-Mail: BlueKnight@technologysecure.com

PGP/GPG ID: 19EC14B3



On Jan 7, 2014, at 8:14 PM, Alex Legler <a3li@gentoo.org> wrote:

> Reads as follows:
> On hppa, there is no fixed version.
> On all other arches, python in slot 3.2 is fixed in >=3.2.9, affected
> for anything less, in the 3.3 slot, [3.3.0; 3.3.1[ and [3.3.3; 3.3.5[
> are affected, for the 0 slot, anything <6.3 is affected.
Re: Soliciting feedback for the GLSA-2 format [ In reply to ]
On 10.01.2014 00:37, Yury German wrote:
> is this what the users will see as generated from XML?

That was just a short example explaining the semantics of the new syntax.

We haven't discussed yet how it'll show up in the text advisory,
probably something like "Slot 3.2: <3.2.1 >3.4.2".
Re: Soliciting feedback for the GLSA-2 format [ In reply to ]
That is the part that would be the most important, as the XML makes sense to me. The translation from XML to GLSA would be the most important part so that it is clear to the general populace.

Whenever I write things for work I am always using the rule of writing to the least common denominator, and I can see this part being the most confusing.

Yury German
E-Mail: BlueKnight@technologysecure.com

PGP/GPG ID: 19EC14B3



On Jan 9, 2014, at 8:35 PM, Tobias Heinlein <keytoaster@gentoo.org> wrote:

> On 10.01.2014 00:37, Yury German wrote:
>> is this what the users will see as generated from XML?
>
> That was just a short example explaining the semantics of the new syntax.
>
> We haven't discussed yet how it'll show up in the text advisory, probably something like "Slot 3.2: <3.2.1 >3.4.2".
>
>
Re: Soliciting feedback for the GLSA-2 format [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/10/2014 02:35 AM, Tobias Heinlein wrote:
> On 10.01.2014 00:37, Yury German wrote:
>> is this what the users will see as generated from XML?
>
> That was just a short example explaining the semantics of the new
> syntax.
>
> We haven't discussed yet how it'll show up in the text advisory,
> probably something like "Slot 3.2: <3.2.1 >3.4.2".
>
>

Might I suggest tabular data for this in the text advisory?
slot | as of | fixed | ...

- --
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Divide et impera
Divide and govern
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJSz68JAAoJEPw7F94F4TagaxYP/Rerni/wxqdmT5ha6O3ZtqeC
lJ4FdkP7UoREO0UxLxumvXaiOOaaswHqHl2q8oupJgqf3TkfoIAEjDb3ovAtaqqX
oodFXvWIOwq4TGayBWfrpFkvNjbN//ceRjhWjWP5t/WDDTy92A2FxLQihwB7gMQK
hiEx2EufHKMae3dw39oW7YWmihoxuel5IWsM3XT/7swfw0ZIeU2l474+obgwHFdc
QUnUOhE+BzEYBNnsh54L5VdL/M2uNO9BKmP6jdWH61/cnR79maA2KpPZ/xbrE8zQ
GIAAMC70F6B/9ZP58/nm7owz11vrLlEA6ynmBFVK4osYye6Zir94Ks6JCwhECu50
MkvM9r8q4qDX7wwL5yfr/hw8s5RbZJDfVtUFWNVeT+8Li+rJoZoa2BSsZDclyhCc
gGH5RM7SGJV58Y0tToYcg0/8C36KR5ZlPD2kZeCFkCsz2ynRx85Mxfme1mQySTjN
EumX4zFhouPtjwlsopt2ubRrFWqnQOhp0aXIuKrw17rfneT0ot+UVecXSK21NEWV
nRWRVPBjuF7WzTSd3mRl62Lb68BBC/pt+qLCQicLuc6Gyi8iB5cJGCXi/i/Oq53a
2igNNg1d4740B+ax3rvcgB+ED2POp/qCDJ9cS3zkPXwmy8nBzAqhx/LbATVV2PMT
XmmibqFRgkyM1aCHncDt
=VMjp
-----END PGP SIGNATURE-----
Soliciting feedback for the GLSA-2 format [ In reply to ]
Hi,

I find the new version of GLSA format very interesting, especially
with the backdrop of the automated evaluation of vulnerabilities.

Would it be possible to specify in which branch of Gentoo, this
program is usually installed? For example, "stable" or "unstable"?

So you can better see if you are actively involved or not.

--
Best regards,
Sascha Wolf
Re: Soliciting feedback for the GLSA-2 format [ In reply to ]
On 10/01/14 10:02 AM, Sascha Wolf wrote:
> Hi,
>
> I find the new version of GLSA format very interesting, especially
> with the backdrop of the automated evaluation of vulnerabilities.
>
> Would it be possible to specify in which branch of Gentoo, this
> program is usually installed? For example, "stable" or "unstable"?
>
> So you can better see if you are actively involved or not.
>

GLSAs are not released if all affected versions are ~arch.
Re: Soliciting feedback for the GLSA-2 format [ In reply to ]
On 1/10/2014 4:02 PM, Sascha Wolf wrote:
> So you can better see if you are actively involved or not.

What do you mean by "involved"? Who is involved in what? In case you
mean glsa-check, it checks every version installed on your system. That
won't be different to the behaviour it already has.
Re: Soliciting feedback for the GLSA-2 format [ In reply to ]
What's wron man? 

-------- Original message --------
From: Tobias Heinlein <keytoaster@gentoo.org>
Date: 10/01/2014 16:44 (GMT+01:00)
To: gentoo-security@lists.gentoo.org
Subject: Re: [gentoo-security] Soliciting feedback for the GLSA-2 format

null
Re: Soliciting feedback for the GLSA-2 format [ In reply to ]
10.01.2014 19:02, Sascha Wolf пишет:
> Hi,
>
> I find the new version of GLSA format very interesting, especially
> with the backdrop of the automated evaluation of vulnerabilities.
>
> Would it be possible to specify in which branch of Gentoo, this
> program is usually installed? For example, "stable" or "unstable"?
>
> So you can better see if you are actively involved or not.
>

Current workflow will not be changed:

- for packages, having stable versions - new versions will be
stabilized, vulnerable versions - removed from tree. GLSA will be
released if it's necessary, AFTER stabilization will be finished for all
security supported arches.
- for packages, that never was in stable - GLSA will NOT be even drafted.

One notable exception for 1) - we do not do GLSAs for kernel packages.

So, to conclude, we track all vulnerabilities, that are discovered in
main portage tree, but GLSAs mainly targeted for stable systems, e.g.
stable branch should not contain vulnerable software(ideally).

--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead