#484256 [uscan] uses active ftp by default

Package:
devscripts
Source:
devscripts
Description:
scripts to make the life of a Debian Package maintainer easier
Submitter:
"Bernhard R. Link"
Date:
2015-12-04 13:33:06 UTC
Severity:
wishlist
#484256#5
Date:
2008-06-03 09:00:54 UTC
From:
To:
uscan does active ftp by default on ftp:// URLs. While this can be
overriden in the watch file and allegdly via some environment variable,
it is no sane default since the days firewalls, NATs and hosts with
multiple IP addresses were invented.

Even worse, when this fails, it does not even output an error message.
Even using --verbose --debug you only get:
| uscan debug: received content:
| [End of received content]
while the ftp server is actually sending errors:
| read(4, "500 Illegal PORT command.\r\n", 1024) = 27

Thanks in advance,
	Bernhard R. Link

#484256#10
Date:
2008-06-03 12:24:43 UTC
From:
To:
Hi,

Bernhard R. Link wrote:

:-D

_Configuration file_ variable rather than environment. It's not allegedly
either, it's in both the default config file and uscan(1) :-)

uscan doesn't actually use either active or passive FTP by default, having
read the code. It uses Net::FTP and if you don't explicitly specify that
active or passive should be used then Net::FTP makes its own mind up.

From Net::FTP(3perl):

"       Passive - If set to a non-zero value then all data transfers will
           be done using passive mode. This is not usually required except
for
           some dumb servers, and some firewall configurations. This can
also
           be set by the environment variable "FTP_PASSIVE".
"

As far as I can see, this means that Net::FTP and/or LWP is claiming that
the request was successful.

I've uploaded a small test script to
http://alioth.debian.org/~adam-guest/ftptest.pl - could you please run it
against the ftp site you were using uscan with and let me know the result?

Regards,

Adam

#484256#15
Date:
2008-06-03 12:49:08 UTC
From:
To:
* Adam D. Barratt <adam@adam-barratt.org.uk> [080603 14:26]:

I think this default in Net::FTP should be changed. It would be nice
if uscan would work around this problem in Net::FTP. Since it already
has an opts=active already documented, doing always passive can do no
harm.
ftp read failed: 500 LWP::Protocol::MyFTP: Bad hostname 'ftp.example.com'

with ftp.gnu.org I get:

| status line: 200 OK
|
| received content:
| [End of receieved content]

Strace still showing it got an error from the ftp server:
| write(3, "PORT 192,168,0,122,131,112\r\n", 28) = 28
| rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
| rt_sigaction(SIGPIPE, {SIG_DFL}, {SIG_IGN}, 0xf7d24838, 1) = 0
| rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
| select(8, [3], NULL, NULL, {20, 0})     = 1 (in [3], left {19, 904000})
| read(3, "500 Illegal PORT command.\r\n", 1024) = 27
| close(4)                                = 0
| close(3)                                = 0
| time(NULL)                              = 1212496687
| write(2, "status line: 200 OK\n", 20status line: 200 OK

I guess that means the missing error message is a fault of Net::FTP,
too.

Not that this is not specific to ftp.gnu.org. It also happens with
all ftp.*.debian.org I tried. (So rejecting a PORT for a not-routed
IP address seems quite common)

Hochachtungsvoll,
	Bernhard R. Link

#484256#20
Date:
2008-06-03 13:22:19 UTC
From:
To:
Bernhard R. Link wrote:
[...]

From a quick scan through perl-modules's bug page, #263552 ("libnet-perl
should default to passive mode on PORT failure") has been forwarded upstream
since August 2004. The forward is the last entry in the bug log.

It potentially swaps people confused by the active default for people
confused by the passive default. :-)


Sorry; I assumed it was obvious you needed to change that :)
[...]

Either Net::FTP itself or LWP::Protcol::ftp certainly look like the culprit,
yeah.

Thanks for testing; that at least rules out a uscan bug on the error
handling side. If it was returning a useful status code or message then we
could have tried matching on that, but as it is... :-(

Regards,

Adam

#484256#25
Date:
2009-03-02 22:52:40 UTC
From:
To:
Package: devscripts
Version: 2.10.46
Followup-For: Bug #484256

Hi,
I have the following uscan output:

zito@bobek:~/deb/ustr/ustr$ uscan
uscan warning: In debian/watch no matching dirs for pattern
  ftp://ftp.and.orgftp://ftp.and.org/pub/james/ustr/(\d+(?:\.\d+)*)
zito@bobek:~/deb/ustr/ustr$ cat debian/watch
version=3
ftp://ftp.and.org/pub/james/ustr/(\d+(?:\.\d+)*)/ustr-(\d+(?:\.\d+)*)\.tar\.gz

Besides the problem with active ftp (I will solve this with 'opts=pasv'
prefix), there is a problem with warning message.
zito@bobek:~/deb/ustr/ustr$ grep 'no matching dirs' /usr/bin/uscan
        warn "$progname warning: In $watchfile no matching dirs for pattern\n  $site$base$pattern\n";

There is a superfluous $site in the above line probably or the string should be
be $site$dir$pattern.

Regards
--- /etc/devscripts.conf --- DEBUILD_DPKG_BUILDPACKAGE_OPTS="'-i\.git/' -I.git"
--- ~/.devscripts --- DEBSIGN_KEYID=FC66B36F
#484256#30
Date:
2015-11-08 12:54:22 UTC
From:
To:
control: severity -1 wishlist

Hi,

As for https://bugs.debian.org/484256#25, I do not see
$site$base$pattern in the recent multitar branch.

Since this is not the original bug issue, let me record here as above
and move on.  (I will file redirection issue as separate bug.)

The default choice is really "wishlist" issue.  It can be set site wise
via USCAN_PASV variable if user needs for his environment.  So I am
moving this to wishlist bug.

Osamu

#484256#39
Date:
2015-12-04 13:31:31 UTC
From:
To:
control: tags -1 wontfix

Hi,

https://bugs.debian.org/484256#30

If the upstream has a reason to chose some default behavior, it should
be respected.  I do not think there is enough reason presented to chose
different default behavior.  This FTP mode issue is mostly issue for the
client network access.  So let the user chose any default by the
existing USCAN_PASV configuration.  That USCAN_PASV option is already
presented.  So no bug to fix.

Regards,

Osamu
PS: The GIT version have better manpage :-)