Bug 140038 - [PATCH] security/vuxml correct opera and linux-opera entry
Summary: [PATCH] security/vuxml correct opera and linux-opera entry
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Security Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-28 05:10 UTC by poyopoyo
Modified: 2009-10-28 23:10 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description poyopoyo 2009-10-28 05:10:01 UTC
linux-opera is marked falsely vulnerable due to different versioning
scheme between www/opera and www/linux-opera.
broken by miwi at 1.2021.
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2009-10-28 05:10:12 UTC
Responsible Changed
From-To: freebsd-ports-bugs->secteam

Over to maintainer (via the GNATS Auto Assign Tool)
Comment 2 poyopoyo 2009-10-28 05:16:44 UTC
patch is here.

--- /usr/ports/security/vuxml/vuln.xml	2009-10-25 23:53:33.000000000 +0900
+++ vuln.xml	2009-10-28 14:05:30.000000000 +0900
@@ -751,9 +751,12 @@
      <affects>
        <package>
          <name>opera</name>
-         <name>linux-opera</name>
          <range><lt>10.00.20090830</lt></range>
        </package>
+       <package>
+         <name>linux-opera</name>
+         <range><lt>10.00</lt></range>
+       </package>
      </affects>
      <description>
        <body xmlns="http://www.w3.org/1999/xhtml">
@@ -779,7 +782,7 @@
      <dates>
        <discovery>2009-09-01</discovery>
        <entry>2009-09-04</entry>
-       <modified>2009-09-04</modified>
+       <modified>2009-10-28</modified>
      </dates>
    </vuln>
Comment 3 Stanislav Sedov 2009-10-28 06:44:48 UTC
On Wed, 28 Oct 2009 05:30:03 GMT
poyopoyo@puripuri.plala.or.jp mentioned:
>  --- /usr/ports/security/vuxml/vuln.xml	2009-10-25 23:53:33.000000000 +0900
>  +++ vuln.xml	2009-10-28 14:05:30.000000000 +0900
>  @@ -751,9 +751,12 @@
>        <affects>
>          <package>
>            <name>opera</name>
>  -         <name>linux-opera</name>
>            <range><lt>10.00.20090830</lt></range>
>          </package>
>  +       <package>
>  +         <name>linux-opera</name>
>  +         <range><lt>10.00</lt></range>
>  +       </package>
>        </affects>
>        <description>
>          <body xmlns="http://www.w3.org/1999/xhtml">
>  @@ -779,7 +782,7 @@
>        <dates>
>          <discovery>2009-09-01</discovery>
>          <entry>2009-09-04</entry>
>  -       <modified>2009-09-04</modified>
>  +       <modified>2009-10-28</modified>
>        </dates>
>      </vuln>
>   

Actually, we never had any linux opera versions between 9.64 and 10.00
in ports collection, so this change is noop.  What is the rationale of
this change?  Was linux version of opera 10.00.20090830 vulnerable? 

-- 
Stanislav Sedov
ST4096-RIPE
Comment 4 poyopoyo 2009-10-28 15:55:49 UTC
At Wed, 28 Oct 2009 09:44:48 +0300,
Stanislav Sedov wrote:
> Actually, we never had any linux opera versions between 9.64 and 10.00
> in ports collection, so this change is noop.  What is the rationale of
> this change?  Was linux version of opera 10.00.20090830 vulnerable? 

in short: 10.00 < 10.00.20090830


long version:
You'd be better to install linux-opera and run portaudit and everythig
you want to know is there.

==
$ pkg_info -I linux-opera\*
linux-opera-10.00_1 A blazingly fast, full-featured, standards-compliant browse
$ portaudit
Affected package: linux-opera-10.00_1
Type of problem: opera -- multiple vulnerabilities.
Reference: <http://portaudit.FreeBSD.org/4582948a-9716-11de-83a5-001999392805.html>
==

There is no such a thing as linux-opera-10.00.20090830. The latest
linux-opera is 10.00_1. This means vuxml is stating every version of
linux-opera is vulnerable. portaudit has been sending this false alert
every day for about two months now.

I wrote in this PR that www/opera and www/linux-opera uses different
versioning scheme, figures:

==
www/opera: PORTVERSION=    ${OPERA_VER}.${OPERA_DATE}
www/opera: OPERA_VER=      10.00
www/opera: OPERA_DATE=     20090830

www/linux-opera: PORTVERSION=    ${OPERA_VER}
www/linux-opera: OPERA_VER=      10.00
==

www/linux-opera does not have $OPERA_DATE suffix and cannot be covered
with PORTVERSION for www/opera. I hope I could explain what this PR
intend to fix.
Comment 5 dfilter service freebsd_committer freebsd_triage 2009-10-28 23:04:44 UTC
stas        2009-10-28 23:04:35 UTC

  FreeBSD ports repository

  Modified files:
    security/vuxml       vuln.xml 
  Log:
  - Fix linux-opera vuxml entry (it uses different version numbering scheme) [1]
  - Add entry for opera-devel as well.
  
  PR:             ports/140038 [1]
  Submitted by:   Sato Kuro <poyopoyo@puripuri.plala.or.jp> [1]
  
  Revision  Changes    Path
  1.2054    +10 -3     ports/security/vuxml/vuln.xml
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 6 Stanislav Sedov freebsd_committer freebsd_triage 2009-10-28 23:05:06 UTC
State Changed
From-To: open->closed

Committed. Thanks!
Comment 7 Stanislav Sedov 2009-10-28 23:06:42 UTC
On Wed, 28 Oct 2009 16:00:04 GMT
poyopoyo@puripuri.plala.or.jp mentioned:

> The following reply was made to PR ports/140038; it has been noted by GNATS.
> 
> From: poyopoyo@puripuri.plala.or.jp
> To: Stanislav Sedov <stas@deglitch.com>
> Cc: bug-followup@FreeBSD.org
> Subject: Re: ports/140038: [PATCH] security/vuxml correct opera and  linux-opera entry
> Date: Thu, 29 Oct 2009 00:55:49 +0900
> 
>  At Wed, 28 Oct 2009 09:44:48 +0300,
>  Stanislav Sedov wrote:
>  > Actually, we never had any linux opera versions between 9.64 and 10.00
>  > in ports collection, so this change is noop.  What is the rationale of
>  > this change?  Was linux version of opera 10.00.20090830 vulnerable? 
>  
>  in short: 10.00 < 10.00.20090830
>  


Oh, I didn't thought about this.  Thanks for explanations!
I added entry for opera-devel as well, while here, as it
appears to be missed.

-- 
Stanislav Sedov
ST4096-RIPE