On Thu, Jul 30, 2015 at 22:35:17 +0200, Francesco Poli wrote: > I have examined your second patch and I have made some > modifications/simplifications to it. > The main behavioral difference with respect to your patch is that I > decided that all the command-line options are to be treated as equally > important: any option specified later on the command line takes > precedence over the ones specified earlier (hence --url will override > --hostname/--port only when it follows them on the command line). > After all, this is how all other command-line options work: specifying > one option multiple times already causes the last specified value to > overwrite the previously specified ones. > For the record, the resulting revised patch is attached.
I thought of this when developing the patch. The problem is that you'll override more than just the host or port unless you're careful. E.g., with -h foo -u https://192.0.2.1:999/bar.cgi -p 443 I think your code will produce "http://foo:443/cgi-bin/soap.cgi";, while I'd expect a URL of "https://192.0.2.1:443/bar.cgi";. Note also that removing -p will change the URL completely. I'm not too concerned though. > Now, the bad news is that I remembered that the libruby module > providing SSL support links with libssl. And the OpenSSL license is > well known to be GPL-incompatible. > apt-listbugs is GPL-licensed and loads a number of GPL-licensed Ruby > libraries: as a consequence, there may be license incompatibility > issues preventing the distribution of a version of apt-listbugs which > uses SSL. > This licensing issue needs to be carefully investigated. > I will try and see what can be done about it. > Sadly, I will have to put the patch aside, until this situation is > solved for the best. This is kind of interesting--it's not clear who would be responsible if libssl got loaded. What if you merged the patch with a non-SSL default for soapurl? It might be useful for someone to override the cgi-bin/... part on a local server, and in terms of libssl it would look the same as before. If some user chose to add an "s", would Debian be responsible? (If so, all users of this SOAP library would need to be audited.) Even if Debian added the "s", would the shipped software be derived from libssl, or would the derived work exist purely in RAM without ever being distributed? It would surprise me if the the presence or absence of "s" in apt-listbugs determines whether it's derived from libssl. We're not using the libssl API, and the underlying libraries could swap it out for something else without us ever noticing. Anyway, I'll leave these things for you to investigate. Thanks for the update. -- Michael
signature.asc
Description: Digital signature
