Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Security

Security project meeting summary

 

 

Gentoo security RSS feed   Index | Next | Previous | View Threaded


vorlon at gentoo

Jul 21, 2008, 11:49 AM

Post #1 of 15 (8340 views)
Permalink
Security project meeting summary

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>

--
Matthias Geerdsen
vorlon [at] gentoo

Gentoo Linux Security Team
http://security.gentoo.org
Attachments: meeting-summary-20080714.txt (7.06 KB)
  signature.asc (0.19 KB)


lazar at mnsu

Jul 21, 2008, 12:04 PM

Post #2 of 15 (8090 views)
Permalink
Re: Security project meeting summary [In reply to]

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


lazar at mnsu

Jul 21, 2008, 12:04 PM

Post #3 of 15 (8100 views)
Permalink
Re: Security project meeting summary [In reply to]

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


rbu at gentoo

Jul 22, 2008, 3:42 AM

Post #4 of 15 (8095 views)
Permalink
Re: Security project meeting summary [In reply to]

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
Attachments: signature.asc (0.82 KB)


erratic at devel

Jul 22, 2008, 11:01 AM

Post #5 of 15 (8082 views)
Permalink
Re: Security project meeting summary [In reply to]

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 [at] gentoo> (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 [at] gentoo> 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
>
>


rbu at gentoo

Jul 22, 2008, 12:04 PM

Post #6 of 15 (8080 views)
Permalink
Re: Security project meeting summary [In reply to]

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 [at] gentoo> (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
Attachments: signature.asc (0.82 KB)


lazar at mnsu

Jul 24, 2008, 10:20 AM

Post #7 of 15 (8066 views)
Permalink
Re: Security project meeting summary [In reply to]

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


lazar at mnsu

Jul 28, 2008, 3:08 PM

Post #8 of 15 (8072 views)
Permalink
Re: Security project meeting summary [In reply to]

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


wviands at chaos

Jul 28, 2008, 4:33 PM

Post #9 of 15 (8047 views)
Permalink
Re: Security project meeting summary [In reply to]

> 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


rbu at gentoo

Jul 28, 2008, 7:13 PM

Post #10 of 15 (8057 views)
Permalink
Re: Security project meeting summary [In reply to]

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
Attachments: signature.asc (0.82 KB)


lazar at mnsu

May 12, 2009, 3:18 PM

Post #11 of 15 (6618 views)
Permalink
Re: Security project meeting summary [In reply to]

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


rbu at gentoo

May 12, 2009, 3:24 PM

Post #12 of 15 (6599 views)
Permalink
Re: Security project meeting summary [In reply to]

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
Attachments: signature.asc (0.82 KB)


lazar at mnsu

May 13, 2009, 3:50 PM

Post #13 of 15 (6601 views)
Permalink
Re: Security project meeting summary [In reply to]

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


pva at gentoo

May 29, 2009, 12:19 AM

Post #14 of 15 (6506 views)
Permalink
Re: Security project meeting summary [In reply to]

В Срд, 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.


lazar at mnsu

Jun 1, 2009, 10:24 AM

Post #15 of 15 (6480 views)
Permalink
Re: Security project meeting summary [In reply to]

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

Gentoo security RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.