bin/173725: portsnap(8) - fix entry validation

jb jb.1234abcd at gmail.com
Mon Nov 19 19:10:01 UTC 2012


>Number:         173725
>Category:       bin
>Synopsis:       portsnap(8) - fix entry validation
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Nov 19 19:10:01 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator:     jb
>Release:        FreeBSD 9.1-RC3 #0
>Organization:
>Environment:
FreeBSD localhost.localdomain 9.1-RC3 FreeBSD 9.1-RC3 #0 r242324: Tue Oct 30 00:18:27 UTC 2012     root at obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

>Description:
# rm -rf /usr/ports
# portsnap fetch update
Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found.
Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Updating from Sun Nov 11 15:54:03 CET 2012 to Mon Nov 19 15:34:57 CET 2012.
Fetching 4 metadata patches... done.
Applying metadata patches... done.
Fetching 0 metadata files... done.
Fetching 24085 patches.....10....20....30....40....50....60....70....80....90...
..
0....24060....24070....24080.. done.
Applying patches... done.
Fetching 18 new ports or files... done.
/usr/ports was not created by portsnap.
You must run 'portsnap extract' before running 'portsnap update'.
#
# ls /usr/ports
ls: /usr/ports: No such file or directory
#

So, the entry did so much work (ca. 5 min, 24085 patches) before aborting
half way and telling user that the env was not set properly up.
With correct entry validation, it should be rejected up front as invalid entry,
even if it applied to the second part ("update"), because the effect of
processing the entire entry ("fetch" plus "update") is lost anyway.

>How-To-Repeat:
as above
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list