Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 89641 - Request to make glsa-check download GLSAs rather than use them from the metadata directory
Summary: Request to make glsa-check download GLSAs rather than use them from the metad...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All All
: Lowest enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on: 534070
Blocks:
  Show dependency tree
 
Reported: 2005-04-19 03:32 UTC by Calum
Modified: 2019-08-19 05:23 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Calum 2005-04-19 03:32:03 UTC
Hello all,

I was surprised to find out that glsa-check uses GLSAs in the metadata sub-directory in portage, synced down by emerge sync.

I was caught out, as I had not been syncing a bandwidth limited machine - instead I was only going to do it when there was a security update available. You can see my problem. No GLSA alerts, so I don't sync, so no GLSA alerts, etc.
I expected the glsa-check package to download (a zip of/a signed zip of ?) the latest GLSAs and check that.

Is it possible to make this change? This would mean that boxes that were stable, and only updated for security reasons, saved a lot of bandwidth on the mirrors, and for the people running them.

Many thanks for your time, and effort in Gentoo anyway.

Calum
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2005-04-19 03:54:31 UTC
+1 for me. ;-)
Comment 2 Peter Jensen 2005-06-14 08:48:57 UTC
This feature would indeed be nice, but for now you can work around it by first
syncing just the glsa part of the portage tree.
However, this illuminates another problem with glsa-check:
If a glsa concerns a package where you have a vulnerable version installed, but
where no "fixed" version exists in portage (perhaps because you don't sync it as
often), then glsa-check will happily mark your version unaffected until you sync
portage.
As it turns out, I've apparently been using an insecure version of tcpdump for
some time because of this ...
Comment 3 Marius Mauch (RETIRED) gentoo-dev 2005-11-15 13:13:00 UTC
Not a quick fix, has some semantic issues.
Comment 4 Paul Varner (RETIRED) gentoo-dev 2010-04-08 16:28:37 UTC
Reopening as this really should be looked at.  Note: the man page does specify that you have to keep the tree synced for glsa-check to be useful.
Comment 5 Zac Medico gentoo-dev 2014-12-16 22:24:00 UTC
(In reply to Peter Jensen from comment #2)
> This feature would indeed be nice, but for now you can work around it by
> first syncing just the glsa part of the portage tree.

@dev-portage:
I think we should add an option to make emerge and/or emaint do this.

> However, this illuminates another problem with glsa-check:
> If a glsa concerns a package where you have a vulnerable version installed,
> but where no "fixed" version exists in portage (perhaps because you don't sync
> it as often), then glsa-check will happily mark your version unaffected until
> you sync portage.
> As it turns out, I've apparently been using an insecure version of tcpdump
> for some time because of this ...

That sounds like a separate bug that needs to be fixed.
Comment 6 Zac Medico gentoo-dev 2014-12-17 20:32:57 UTC
(In reply to Zac Medico from comment #5)
> (In reply to Peter Jensen from comment #2)
> > This feature would indeed be nice, but for now you can work around it by
> > first syncing just the glsa part of the portage tree.
> 
> @dev-portage:
> I think we should add an option to make emerge and/or emaint do this.

I've posted a proposal here:

	http://thread.gmane.org/gmane.linux.gentoo.portage.devel/5015
Comment 7 Michael Orlitzky gentoo-dev 2014-12-17 20:48:26 UTC
> I've posted a proposal

I don't think that really addresses the (original) issue: now you have to know about and run `emerge --sync-glsa` all the time for glsa-check to work.

Unless you also propose to make glsa-check run `emerge --sync-glsa` before it does its thing? That could do it.

I would prefer to see the GLSAs moved to a separate git repo (which glsa-check could sync), but hey.
Comment 8 Zac Medico gentoo-dev 2014-12-17 20:58:17 UTC
(In reply to Michael Orlitzky from comment #7)
> > I've posted a proposal
> 
> I don't think that really addresses the (original) issue: now you have to
> know about and run `emerge --sync-glsa` all the time for glsa-check to work.

It's no worse than the current situation where you have to run emerge --sync, but it is better because you don't have to sync the whole tree when all you want is the glsa data.
 
> Unless you also propose to make glsa-check run `emerge --sync-glsa` before
> it does its thing? That could do it.

Sure, we could do that. It's a separate feature that depends on the new `emerge --sync-glsa` feature, though.

> I would prefer to see the GLSAs moved to a separate git repo (which
> glsa-check could sync), but hey.

We could do that, but we'd probably still want to merge them into the rsync tree as we do now. That way, we can still leverage the rsync tree for load-balancing.
Comment 9 Michael Orlitzky gentoo-dev 2014-12-17 21:57:37 UTC
Sounds good then. It may be worth considering e.g. a `--sync-only` option, ala,

  $ emerge --sync-only=metadata/glsa

which could serve the same purpose for other subdirectories, like metadata/news. But it has the problem that the tree as a whole is supposed to be consistent, and you can break things by updating only a subtree.

I'd be fine with saying "don't do that" if it causes problems.
Comment 10 Zac Medico gentoo-dev 2014-12-17 22:06:39 UTC
(In reply to Michael Orlitzky from comment #9)
> Sounds good then. It may be worth considering e.g. a `--sync-only` option,
> ala,
> 
>   $ emerge --sync-only=metadata/glsa

I think that would expose too much of the implementation details. The intention of the proposed --sync-glsa action is to abstract away the implementation details. That way, the repository layout could change, but --sync-glsa would continue to "do the right thing" as long as we update the code.
Comment 11 Zac Medico gentoo-dev 2014-12-27 11:30:56 UTC
I've started working on user-interfaces for emerge and emaint in following branch:

	https://github.com/zmedico/portage/tree/sync-submodule

This adds support for a new --sync-submodule <glsa|news|profiles> option to both emerge and emaint. When this option is used with the sync action, only the selected submodules are synced. Each submodule is referenced using an abstract identifier, which serves to hide the implementation details involving the precise locations of specific submodules within each repository.
Comment 12 Zac Medico gentoo-dev 2014-12-31 08:17:59 UTC
(In reply to Zac Medico from comment #11)
> This adds support for a new --sync-submodule <glsa|news|profiles> option

I've filed bug 534070 for this feature, and I've posted a working patch for it.
Comment 13 Zac Medico gentoo-dev 2019-08-19 05:22:49 UTC
glsa-check is included with >=sys-apps/portage-2.3.72 (bug 463952).