# Updating packages based on glsa-check output

## abduct

This may be a super simple question, but how do you fix problems that glsa-check finds by hand?

I don't quite trust an experimental tool to patch my system itself especially since the option within gsla-check --help says "experimental" in the description.

Do I just emerge the up to date packages like I would normally update software, or does glsa-check apply some sort of patches it pulls from else where where emerge does not.

Here is a sample list of what I'm trying to update if it helps: 

 *Quote:*   

> 
> 
> 201504-01 [N] [remote  ] Mozilla Products: Multiple vulnerabilities ( mail-client/thunderbird  www-client/seamonkey-bin  mail-client/thunderbird-bin  www-client/firefox-31.5.0  www-client/seamonkey  www-client/firefox-bin  dev-libs/nspr-4.10.7-r1 )
> 
> 201504-02 [N] [local   ] sudo: Information disclosure ( app-admin/sudo-1.8.11_p1 )
> ...

 

Thanks!

----------

## skiwarz

If you browse through some of the GLSAs posted at https://security.gentoo.org/glsa it seems like the resolution for all of them is to update to the latest version. So whether you do so manually or use glsa-check -f to apply that resolution (update your programs), I suppose the same end result is effected.

As far as whether there is some "extra code" that GLSA-check pulls in, I doubt it. That code would eventually have to be patched into newer versions of the program anyways, so wouldn't they just release a new version of the program instead of having a separate "patch"? I don't know exactly how glsa-check works, but it seems like a pretty simple program. You could always browse the source code to find an exact answer  :Wink: 

Are you getting those results from glsa-check before or after  you update your system? ie [emerge -uDN world] or something similar

----------

## depontius

Years back, I ran my mother's computer this way.  I'm sorry to say that I don't remember the scripts I used to do the job.

We'd visit every fall and spring, and I'd completely update her computer while we were there.  In between I ran updates based on glsa-check, essentially a security-fixes-only policy.  You're right, in that it's usually updating to the latest version, but it's a question of how much of the system do you want to update.  Most times Gentoo updates easily, but sometimes there's a problem like expat, or gcc or xorg updates are usually messy.  I prefer to save things like that, along with kernel updates, for when I'm physically present.

----------

## abduct

 *skiwarz wrote:*   

> If you browse through some of the GLSAs posted at https://security.gentoo.org/glsa it seems like the resolution for all of them is to update to the latest version. So whether you do so manually or use glsa-check -f to apply that resolution (update your programs), I suppose the same end result is effected.
> 
> Are you getting those results from glsa-check before or after  you update your system? ie [emerge -uDN world] or something similar

 

Yea I took a look at that but wasn't too sure what exactly glsa-check did to "fix" the problems. I'd rather not have a script pull in every dependency and its dog just to recompile a piece of software if I don't need to recompile its dependencies for the affected software.

I am getting the results before updating. I wanted to wait for an answer before updating the packages myself. I like to believe in the whole "if it works fine, don't fix it" policy so I rarely keep my software up to date except for when advisories or known bugs arise. I think this is more or less because I haven't been keeping my USE flags and ACCEPT_KEYWORDS masks up to date, so if I update world it may break something or simple fail half way through.

If there is a command or script that I can run that parses everything currently installed and fixes those files that would be genius.

 *depontius wrote:*   

> Years back, I ran my mother's computer this way.  I'm sorry to say that I don't remember the scripts I used to do the job.
> 
> We'd visit every fall and spring, and I'd completely update her computer while we were there.  In between I ran updates based on glsa-check, essentially a security-fixes-only policy.  You're right, in that it's usually updating to the latest version, but it's a question of how much of the system do you want to update.  Most times Gentoo updates easily, but sometimes there's a problem like expat, or gcc or xorg updates are usually messy.  I prefer to save things like that, along with kernel updates, for when I'm physically present.

 

This is basically how I live on all my systems. Not so much because I don't nessiarly hate changes or up to date software, but because if I tried to update stuff it would most likely break due to me not keeping up on emerge variables like USE flags and ACCEPT_KEYWORD unmasks.

----------

## skiwarz

Here's what "glsa-check -f" does:

```
      elif mode == "fix":

         if not quiet:

            sys.stdout.write("Fixing GLSA "+myid+"\n")

         if not myglsa.isVulnerable():

            if not quiet:

               sys.stdout.write(">>> no vulnerable packages installed\n")

         else:

            if quiet:

               sys.stdout.write("Fixing GLSA "+myid+"\n")

            mergelist = myglsa.getMergeList(least_change=least_change)

            if mergelist == []:

               sys.stdout.write(">>> cannot fix GLSA, no unaffected packages available\n")

               sys.exit(2)

            for pkg in mergelist:

               sys.stdout.write(">>> merging "+pkg+"\n")

               # using emerge for the actual merging as it contains the dependency

               # code and we want to be consistent in behaviour. Also this functionality

               # will be integrated in emerge later, so it shouldn't hurt much.

               emergecmd = "emerge --oneshot " + glsaconfig["EMERGE_OPTS"] + " =" + pkg

               if verbose:

                  sys.stderr.write(emergecmd+"\n")

               exitcode = os.system(emergecmd)

               # system() returns the exitcode in the high byte of a 16bit integer

               if exitcode >= 1 << 8:

                  exitcode >>= 8

               if exitcode:

                  sys.exit(exitcode)

            if len(mergelist):

               sys.stdout.write("\n")
```

So, all it does is emerge the new packages.

And I'm guessing that that line "myglsa.getmergelist(least_change=least_change)" means select the "oldest fixed version of the program"... but I don't know.

----------

## abduct

I see I started to view the code as well after finding it and came to the same conclusion.

I also had to do some research what --oneshot did. I knew the basis to it but not really what if effected at the time.

I also played around with some more of the options such as -p and the "affected" identifiers which printed out what it would update to patch the advisory as well as which version it would pull in.

I also have demerge installed so now if something absolutely does go wrong I can attempt to at least revert back to a previous restore point to recompile the original versions of software with *hopefully* not to much damage.

-------------------------------------

I don't see it trying to figure out use flags or anything so does emerge already know which custom flags you used per package when updating? Since I might of forgot to put some custom use flags to customize specific software into the make.conf or other related files.

I'd hate for it to update something and just use default USE flags when I decided to use some other flags with it.

Thanks for the help so far.

----------

## skiwarz

I'm not an expert on this stuff, so I could be wrong here. But I think it would use whatever flags are given in the config files. So all your flags from make.conf and any you specified in package.use. But if you emerged the program with command-line use flags, those will be excluded. I could be wrong, but that makes sense to me. I haven't looked at the code too much.

----------

## abduct

 *skiwarz wrote:*   

> I'm not an expert on this stuff, so I could be wrong here. But I think it would use whatever flags are given in the config files. So all your flags from make.conf and any you specified in package.use. But if you emerged the program with command-line use flags, those will be excluded. I could be wrong, but that makes sense to me. I haven't looked at the code too much.

 

I was afraid you would say that. Some software (more so user software than system software) I provided custom use flags on the command line.

Time to google around and see if theres any script or way to parse all use flags for each application and create a make.conf USE list containing them all.

----------

## skiwarz

Isn't there a way to do that with equery or something? I could have sworn I've looked up which use flags I compiled with for specific programs before.

----------

## abduct

There's no automated way, but I worked around it. I don't plan on doing a full system update any time soon so I just ran `equery uses <pgk>` on all the outputs that glsa-check gave me and double checked if their use flags were in a make.conf. If they wern't I used `euse -E <use flag>` to add them to which ever make.conf it uses (I believe it's the one in /etc/portage rather than /etc/make.conf).

Once this is done I went and ran `glsa-check -v -f affected` which is currently doing it's job. I really wish they had a --pretend option to see what it will actually do before running it for real. I'll have to see if I can track down the dev or something about it.

Thanks for all the support.

----------

## skiwarz

If you wanted to use the --pretend option, I remember seeing in the glsa-check script where it says 

```
emergecmd = "emerge --oneshot " + glsaconfig["EMERGE_OPTS"] + " =" + pkg 
```

 you could either track down where it grabs EMERGE_OPTS from, or just add in a "--pretend" to this line. Then after you examine it, delete the "--pretend" and run it again.

----------

