Mailing List Archive

Hello. Would it be reasonable to suggest adding a ~security (or
something like it) flag to denote packages masked for security reasons?

Thanks.
Aleksey

Matthias Geerdsen wrote:
> Hi,
>
> I attached a summary of last week's meeting. The summary and the log
> are also linked from [1] and should find their way to our /proj dir in
> the end.
>
> Matthias
>
>
> [1] <http://dev.gentoo.org/~vorlon/security/meeting-20080714.xml>
>

--
Aleksey V. Lazar
Website Development
Memorial Library 3010
Minnesota State University
Mankato, MN 56001
http://www.mnsu.edu/
Tel.: 1-507-389-2480

Hello. Would it be reasonable to suggest adding a ~security (or
something like it) flag to denote packages masked for security reasons?

Thanks.
Aleksey

Matthias Geerdsen wrote:
> Hi,
>
> I attached a summary of last week's meeting. The summary and the log
> are also linked from [1] and should find their way to our /proj dir in
> the end.
>
> Matthias
>
>
> [1] <http://dev.gentoo.org/~vorlon/security/meeting-20080714.xml>
>

--
Aleksey V. Lazar
Website Development
Memorial Library 3010
Minnesota State University
Mankato, MN 56001
http://www.mnsu.edu/
Tel.: 1-507-389-2480

On Monday 21 July 2008, Aleksey V Lazar wrote:
> Hello. Would it be reasonable to suggest adding a ~security (or
> something like it) flag to denote packages masked for security
> reasons?

Hi Aleksey,

since entries package.mask only contain free text description as an
additional information, such a feature would require the package
manager to decide which entries are security maskings, and which are
feature maskings. While that could be done using
restrictions/conventions within the text, I am sure our package manager
developers would disagree with such a design. A "package.security.mask"
file might be more appropriate for that.

My question now is, why would you want such a thing? Masked packages all
have different reasons to be there, and you should decide to use one on
a case-by-case basis.

Regards,
Robert

misfit[1004]:~% sudo emerge -uva nethack
Password:

These are the packages that would be merged, in order:

Calculating dependencies |
!!! All ebuilds that could satisfy "games-roguelike/nethack" have been
masked.
!!! One of the following masked packages is required to complete your
request:
- games-roguelike/nethack-3.4.3-r1 (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Tavis Ormandy <taviso@gentoo.org> (21 Mar 2006)
# masked pending unresolved security issues #125902


For more information, see MASKED PACKAGES section in the emerge man page or
refer to the Gentoo Handbook.

misfit[1005]:~%




On Tue, Jul 22, 2008 at 3:42 AM, Robert Buchholz <rbu@gentoo.org> wrote:

> On Monday 21 July 2008, Aleksey V Lazar wrote:
> > Hello. Would it be reasonable to suggest adding a ~security (or
> > something like it) flag to denote packages masked for security
> > reasons?
>
> Hi Aleksey,
>
> since entries package.mask only contain free text description as an
> additional information, such a feature would require the package
> manager to decide which entries are security maskings, and which are
> feature maskings. While that could be done using
> restrictions/conventions within the text, I am sure our package manager
> developers would disagree with such a design. A "package.security.mask"
> file might be more appropriate for that.
>
> My question now is, why would you want such a thing? Masked packages all
> have different reasons to be there, and you should decide to use one on
> a case-by-case basis.
>
> Regards,
> Robert
>
>

On Tuesday 22 July 2008, Paige Thompson wrote:
> misfit[1004]:~% sudo emerge -uva nethack
> Password:
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies |
> !!! All ebuilds that could satisfy "games-roguelike/nethack" have
> been masked.
> !!! One of the following masked packages is required to complete your
> request:
> - games-roguelike/nethack-3.4.3-r1 (masked by: package.mask)
> /usr/portage/profiles/package.mask:
> # Tavis Ormandy <taviso@gentoo.org> (21 Mar 2006)
> # masked pending unresolved security issues #125902
>
>
> For more information, see MASKED PACKAGES section in the emerge man
> page or refer to the Gentoo Handbook.

Sorry, I do not understand the point you are trying to make. Nethack has
an unresolved security bug, and if you want to install it anyway, put
it in your /etc/portage/package.unmask -- as described in
"man emerge". I do not see the gain by setting up a system that would
completely ignore *all* security-related package masks.


Robert

Pierre-Yves Rofes wrote:
> On Mon, July 21, 2008 9:04 pm, Aleksey V Lazar wrote:
>
>> Hello. Would it be reasonable to suggest adding a ~security (or
>> something like it) flag to denote packages masked for security reasons?
>>
>> Thanks.
>> Aleksey
>>
>>
>
> Hello,
>
> by "~security" you mean a keyword like ~x86 ? It's not a hardware
> architecture, so it wouldn't make much sense. But having a way to list
> masked packages for security reasons is indeed a good idea. The problem
> is finding how to do it "the right way".
>
>
> --
> Pierre-Yves Rofes
> Gentoo Linux Security Team
>
>
I was thinking more along the lines of adding a special mark to the list
that currently includes "~", "+" and "M". Let's say it would be "!".
This mark could then be used for package versions with security
problems. I don't know if this is technically possible, but I could see
"!" used in conjunction with the "~", "+" or "M" to alert/indicate a
security issue, like "~!", or "+!" or "M!". I think this is what I meant.

Thanks.
Aleksey

--
Aleksey V. Lazar
Website Development
Memorial Library 3010
Minnesota State University
Mankato, MN 56001
http://www.mnsu.edu/
Tel.: 1-507-389-2480

Hello, Robert:

Robert Buchholz wrote:
> On Monday 21 July 2008, Aleksey V Lazar wrote:
>
>> Hello. Would it be reasonable to suggest adding a ~security (or
>> something like it) flag to denote packages masked for security
>> reasons?
>>
>
> Hi Aleksey,
>
> since entries package.mask only contain free text description as an
> additional information, such a feature would require the package
> manager to decide which entries are security maskings, and which are
> feature maskings. While that could be done using
> restrictions/conventions within the text, I am sure our package manager
> developers would disagree with such a design. A "package.security.mask"
> file might be more appropriate for that.
>
Are you saying that security mask entries would go into the
package.security.mask and feature/other to package.mask? I think this
would make sense.
> My question now is, why would you want such a thing? Masked packages all
> have different reasons to be there, and you should decide to use one on
> a case-by-case basis.
>
I described in some more detail what I was thinking about in my previous
post to this list.

To answer your question, I think a feature like this would be very
useful, because it would remove barriers for identifying packages with
security issues. For example, I don't update my gentoo system daily,
but I would update it as often as necessary to keep it secure.
Currently (to the best of my understanding) there is no easy way (e.g.:
an /emerge/ option) to identify and update only the packages that have
security fixes. I would have to do some digging to find out what
packages and evaluate each package separately. So I think there would
be value in separating security masking from other types. To summarize,
I think this would accomplish the following:

1. Easily identify packages masked for security reasons.
2. Easily identified installed packages that have security issues/fixes
available.
3. Option for /emerge/ to only update packages with security fixes

Thank you for consideration.
Aleksey
> Regards,
> Robert
>
>

--
Aleksey V. Lazar
Website Development
Memorial Library 3010
Minnesota State University
Mankato, MN 56001
http://www.mnsu.edu/
Tel.: 1-507-389-2480

> Currently (to the best of my understanding) there is no easy way (e.g.:
> an /emerge/ option) to identify and update only the packages that have
> security fixes.

This doesn't work anymore?

1. emerge --sync (emerge-webrsync)
2. glsa-check -p affected
3. glsa-check -f affected
4. env-update
5. revdep-rebuild


Bill

On Tuesday 29 July 2008, Bill wrote:
> > Currently (to the best of my understanding) there is no easy way
> > (e.g.: an /emerge/ option) to identify and update only the packages
> > that have security fixes.
>
> This doesn't work anymore?
>
> 1. emerge --sync (emerge-webrsync)
> 2. glsa-check -p affected
> 3. glsa-check -f affected
> 4. env-update
> 5. revdep-rebuild

GLSA support has also been integrated into Portage 2.2, so you can do
something along the lines of
# emerge --update @security


Robert

Robert Buchholz wrote:
> On Tuesday 29 July 2008, Bill wrote:
>
>>> Currently (to the best of my understanding) there is no easy way
>>> (e.g.: an /emerge/ option) to identify and update only the packages
>>> that have security fixes.
>>>
>> This doesn't work anymore?
>>
>> 1. emerge --sync (emerge-webrsync)
>> 2. glsa-check -p affected
>> 3. glsa-check -f affected
>> 4. env-update
>> 5. revdep-rebuild
>>
>
> GLSA support has also been integrated into Portage 2.2, so you can do
> something along the lines of
> # emerge --update @security
>
This no longer seems to work for me. Is there a new way to accomplish
the task?
>
> Robert
>

--
Aleksey V. Lazar
Website Development
Memorial Library 3010
Minnesota State University
Mankato, MN 56001
http://www.mnsu.edu/
Tel.: 1-507-389-2480

On Wednesday 13 May 2009, Aleksey V Lazar wrote:
> Robert Buchholz wrote:
> > On Tuesday 29 July 2008, Bill wrote:
> >>> Currently (to the best of my understanding) there is no easy way
> >>> (e.g.: an /emerge/ option) to identify and update only the
> >>> packages that have security fixes.
> >>
> >> This doesn't work anymore?
> >>
> >> 1. emerge --sync (emerge-webrsync)
> >> 2. glsa-check -p affected
> >> 3. glsa-check -f affected
> >> 4. env-update
> >> 5. revdep-rebuild
> >
> > GLSA support has also been integrated into Portage 2.2, so you can
> > do something along the lines of
> > # emerge --update @security
>
> This no longer seems to work for me. Is there a new way to
> accomplish the task?

Which Portage version are you on, specifically? If it is Portage 2.2,
this might be a bug. If it is Portage 2.1, you are not using a recent
enough Portage version.


Robert

Robert Buchholz wrote:
> On Wednesday 13 May 2009, Aleksey V Lazar wrote:
>
>> Robert Buchholz wrote:
>>
>>> On Tuesday 29 July 2008, Bill wrote:
>>>
>>>>> Currently (to the best of my understanding) there is no easy way
>>>>> (e.g.: an /emerge/ option) to identify and update only the
>>>>> packages that have security fixes.
>>>>>
>>>> This doesn't work anymore?
>>>>
>>>> 1. emerge --sync (emerge-webrsync)
>>>> 2. glsa-check -p affected
>>>> 3. glsa-check -f affected
>>>> 4. env-update
>>>> 5. revdep-rebuild
>>>>
>>> GLSA support has also been integrated into Portage 2.2, so you can
>>> do something along the lines of
>>> # emerge --update @security
>>>
>> This no longer seems to work for me. Is there a new way to
>> accomplish the task?
>>
>
> Which Portage version are you on, specifically? If it is Portage 2.2,
> this might be a bug. If it is Portage 2.1, you are not using a recent
> enough Portage version.
>
>
> Robert
>
I'm using Portage version 2.1.6.13 right now. I know for a fact that
I've used the emerge --update @security command before (right around 29
July 2008). The command stopped working since then, apparently. Thanks.

--
Aleksey V. Lazar
Website Development
Minnesota State University

В Срд, 13/05/2009 в 17:50 -0500, Aleksey V Lazar пишет:

> I'm using Portage version 2.1.6.13 right now. I know for a fact that
> I've used the emerge --update @security command before (right around
> 29 July 2008). The command stopped working since then, apparently.
> Thanks.

Check your emerge.log. You had portage-2.2* installed at that time.
portage-2.2 was hard masked later to force all users downgrade to
portage-2.1.6 - portage branch with backported stable features from
portage-2.2. If you still wish to use emerge --update @security you'll
have manually unmask portage-2.2 using /etc/portage/package.unmask (see
handbook and/or man portage for more info). But note, portage-2.2 was
masked for a reason ;)

--
Peter.

Peter Volkov wrote:
> В Срд, 13/05/2009 в 17:50 -0500, Aleksey V Lazar пишет:
>
>
>> I'm using Portage version 2.1.6.13 right now. I know for a fact that
>> I've used the emerge --update @security command before (right around
>> 29 July 2008). The command stopped working since then, apparently.
>> Thanks.
>>
>
> Check your emerge.log. You had portage-2.2* installed at that time.
> portage-2.2 was hard masked later to force all users downgrade to
> portage-2.1.6 - portage branch with backported stable features from
> portage-2.2. If you still wish to use emerge --update @security you'll
> have manually unmask portage-2.2 using /etc/portage/package.unmask (see
> handbook and/or man portage for more info). But note, portage-2.2 was
> masked for a reason ;)
>
>
This explains it. Thanks, Peter.

--
Aleksey V. Lazar