On Fri, 17 Jul 2015 19:13:35 -0400 Michael Gold wrote: > 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.
Sure, that's clear. [...] > > 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. Perfect, thanks for confirming this! I'll add copyright notices like "Copyright (C) 2015 Michael Gold <[email protected]>" to the relevant files and to the debian/copyright file, when I integrate you patch into apt-listbugs. > > > • 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; I don't know for sure, since I found them already implemented when I adopted the package, but I guess they are useful when a non-Debian debbugs instance has to be used (I am thinking about a Debian derivative distro with its own debbugs-based BTS, for instance... I am not aware of any such distro, but who knows?). > 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). OK, this looks like a reasonable rationale. > > I recommend removing --hostname and --port from the manual eventually, > to simplify it. But I don't think they complicate the code too much. Let's label those two options as deprecated for the time being. They will be ready to be removed after the release of stretch, I would say... > > > • 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. OK, this seems to be reasonable. > > 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? It's an interesting idea, but let's not complicate things too much. I can certainly live with the need to explicitly specify "/cgi-bin/soap.cgi", especially taking into account that this need only arises when a non-default URL has to be used. > > > • 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. Good, thanks. > > > Finally, could you please re-base your patch against the current tip of > > the master branch on the public git repository? > > OK. Thank you very much, your helpfulness is really appreciated! I am looking forward to seeing your updated patch. Please send it as soon as it's ready. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpptKxp6x8ic.pgp
Description: PGP signature
