On Fri, Jul 17, 2015 at 20:20:16 +0200, Francesco Poli wrote: > On Thu, 16 Jul 2015 20:44:14 -0400 Michael Gold wrote: > Well, more packages than versions, I would say, but anyway I fully > acknowledge that some information is leaked. > In some scenarios, one would prefer to keep these data undisclosed.
And by enabling it by default, those people will not stand out. > This is good news, I wasn't aware that the Debian BTS SOAP interface > was already able to be used through HTTPS! > Actually, I admit that I haven't tried to find documentation about > this... I don't recall seeing any email or documentation, but I noticed that the canonical BTS URLs changed to use https recently (if you use "http:" it will redirect). > I assume that you're contributing this patch (copyrighted by you as an > individual) under the same terms as apt-listbugs (GNU GPL v2 or later). > Please confirm this. Yes. > • obviously, it would have been simpler to just switch from http to > https and add a --disable-ssl option for those who need unencrypted > SOAP connections: please elaborate a bit on the rationale behind such a > more sophisticated approach (deprecate two options, which still are > supported and provide the old behavior, add another option that > supports arbitrary URLs); I guess the main reason is that you really > value backward compatibility...? It's not clear to me why the --hostname and --port options exist; and without knowing that, it's hard for me to know what will break by just enabling TLS. If the intention is to allow users to set up their own servers, I expect they'll have no (valid) TLS there, and they'll have to adjust their setup to add some --disable option. And I guess you'd want to show a notice about the change when upgrading (I find it annoying when apt assigns me busywork like this). I recommend removing --hostname and --port from the manual eventually, to simplify it. But I don't think they complicate the code too much. > • why should the user need to explicitly specify "/cgi-bin/soap.cgi"? > after all, it has been automatically added by apt-listbugs so far... > the user could just specify --url "https://bugs.debian.org:443"; and the > remainder could be added transparently; are there relevant scenarios > where that last part of the URL won't be "/cgi-bin/soap.cgi"? or is it > just "who knows?" If we expect some users to run their own servers, the default path does seem too generic. But the real reason is because I considered adding an option to specify TLS or non-TLS, and noticed it would be a roundabout way to give a URL (especially if someone later requests a way to override "soap.cgi"). It's trickier to put into a config file and makes backward compatibility harder. The URL is the standard way to specify everything we need to know, and it's what the library wants anyway. Your note does give me an idea: if the URL doesn't contain a slash after the :// part, we could append "/cgi-bin/soap.cgi". What do you think? > • I would prefer if the online help showed the current value of > @soapurl between brackets, rather than its default value: apt-listbugs > does so for other options; for instance I didn't notice that. I'll change it. > Finally, could you please re-base your patch against the current tip of > the master branch on the public git repository? OK. -- Michael
signature.asc
Description: Digital signature
