Hi ! Suppose that xxxx 3.0.1-5 fixes a vulnerability. Therefore, 3.0.1-4 is vulnerable. Assume that I backport 3.0.1-5 to etch. I will name this version 3.0.1-5~bpo.1. Because of "~", this version will be considered as inferior to 3.0.1-5 and will be marked as vulnerable. I think that this "inferiority" should be changed to equality in term of security. I suppose that __cmp__() in Version class could return 0 when all the following conditions are met: - upstream versions are equal - debian versions of the package without r'~.*$' pattern are equal Otherwise, we just use return VersionCompare() result. I attach a proposed (ugly) patch. If you think this behaviour is too dangerous, you could add a flag '--enable-backports-support'. Thanks.
OoO La nuit ayant déjà recouvert d'encre ce jour du samedi 08 mars 2008, vers 23:36, je disais: My patch did not consider the fact that '~' was also used in testing security. I don't really understand what '~' means in this case and therefore, I don't know if my patch is still valid.
* Vincent Bernat: This doesn't work because "~" isn't really that special. It's used by maintainers as well, not just backports and testing-security. Sorry, but the fix is more complex, and I'm not 100% sure what it would look like. It probably has to happen on the server side anyway.
OoO En cette fin de nuit blanche du dimanche 09 mars 2008, vers 05:49, Florian Weimer <fw@deneb.enyo.de> disait: Do you have other examples? I did not find one. I emphasize the fact that we only consider '~' in the debian version part, not in upstream version. Backports are not official and can come from various sources (backports.org or backports made by hand). I don't see how you could handle this on server side.
OoO En cette fin de nuit blanche du dimanche 09 mars 2008, vers 05:49, Florian Weimer <fw@deneb.enyo.de> disait: Well, I have another idea. We could add an option that will normalize package versions by stripping some data. For example, debsecan could be invoked with --normalize='~bpo.\d+' to support backports. Or we could use --normalize='(~bpo|+custom).\d+' to support both backports and custom packages. I'll send you a patch implementing this.
OoO En cette fin de nuit blanche du dimanche 09 mars 2008, vers 05:49, Florian Weimer <fw@deneb.enyo.de> disait: will be stripped from the version. If debsecan is called with: --strip-version '~bpo.\d+$' then, backports version will be compared against their testing/unstable counterparts.
Since backports.org is (pseudo?)official, and it's very unlikely to see a ~bpo.\d+ version on a package not coming from backports.org, can't we just hardcode that any ~bpo.\d+ version is stripped off automatically before the compare? Vincent's last patch can be useful but I would propose to add ~bpo.\d+ by default to the list of strippable regexps... Thijs
I am not 100% sure if I have the same error as the OP, but I think so.
I am getting this warning:
CVE-2010-3315 authz.c in the mod_dav_svn module for the Apache HTTP...
<http://security-tracker.debian.net/tracker/CVE-2010-3315>
- libsvn-perl, subversion-tools, subversion, libapache2-svn, libsvn1,
python-subversion (remotely exploitable, medium urgency)
I have subversion: 1.6.12dfsg-2~bpo50+1 installed.
But, that is reported as fixed here:
http://security-tracker.debian.org/tracker/CVE-2010-3315
Thanks.
Hi! No update on this bug. My patch seems to be better than nothing at all. How about using it waiting for a better solution?
Hello, it's 2016 and this "bug" is still there. I have nginx from jessie-backports ( 1.9.10-1~bpo8+1 ) which is not affected by this CVE - https://security-tracker.debian.org/tracker/CVE-2016-0746 - but debsecan still says I have affected version. For detecting backports - they now have "~bpo" in their version. Regards, Marqin
Hi Florian, since debsecan came up as a candidate for the bug of the day. I have verified bugs tagged patch. I left #470065 debsecan: Better report for backports #588064 Parse config file before option checking #725934 debsecan: automatically add apt pinning for packages with security issues untouched (submitters of patches in CC) since the package is now several versions ahead. I would prefer if submitters could verify the patches and possibly provide MRs. For this purpose and to enable you checking what exactly was NMUed I migrated the package to Salsa at https://salsa.debian.org/debian/debsecan If you do not agree with the Salsa migration please update your clone that used to be at gitlab and I will cancel the upload - and for sure let me know if you have other reasons for making me cancel the upload to delayed=15. Kind regards Andreas.