Ugh. Seems I just ran into a brick wall on this one.
Thinking our parsers were incorrectly dropping the
epoch was itself incorrect. The epoch portions of
the version strings are actually not readily available
in the advisories.

That makes Chandra's original suggestion probably the
best one - to drop the epoch. It does mean that we
may have a few cases to deal with where an epoch
change results in a script failure. But those are
probably more easily handled as one-off situations at
this point in time.

Thomas

Thomas Reinke wrote:
> Chandrashekhar B wrote:
>> For some of the packages on Ubuntu, such as, 
>>
>> openoffice.org-help-en-us    2.4.1-1ubuntu2.1
>>
>> when you run dpkg -l, it returns,
>>
>> openoffice.org-help-en-us    1:2.4.1-1ubuntu2.1
>>
>> Some local checks are failing because of this, since the version comparison
>> fails. I guess the same thing happens on Debian too. We plan to update the
>> pkg-lib-deb.inc to exclude 'n:' (if that exists in the package version)
>> before comparison. Anybody sees issue with that?
> 
> Hmm...that's a new one for us.  Having looked into it, though, the
> fix isn't in pkg-lib-deb.inc.  The 'n:' at the start of
> a package version string is called the epoch. It is deliberately
> placed there to provide an additional sort should there either
> be version number errors, or should an old version numbering scheme
> be chosen to be left behind.  As such, it does form an integral
> part of the version number and cannot just be dropped.
> http://manpages.ubuntu.com/manpages/intrepid/man5/deb-version.5.html
> 
> The correct fix is to go back and update the local security checks
> that dropped the 'n:' off the version number when parsing the
> various checks.
> 
> It seems in Debian the epoch was added post Debian 4.0, while
> in Ubuntu it's showing up in the 8.x streams.
> 
> Since we're the source of the problem on this one, I suggest
> we fix it. I should be able to commit an update later on today.
> 
> Thomas
> 
> 
> 
> _______________________________________________
> Openvas-discuss mailing list
> [email protected]
> http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
> 

_______________________________________________
Openvas-discuss mailing list
[email protected]
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Reply via email to