Dear all,
whilst packaging we've had a look at the licenses. Most things are ok, but there might be a problem with the asn_lookup expert.
It makes use of pyasn (MIT-License) which builds on other products with different lisenses. One of them (mrtd) uses a 4-Clause BSD license which might be incompatible to AGPL.
Do you know of alternatives to pyasn?
Best Regards Dustin
On 2016/04/01 13:04, Dustin Demuth dustin.demuth@intevation.de wrote:
Dear all,
whilst packaging we've had a look at the licenses. Most things are ok, but there might be a problem with the asn_lookup expert.
It makes use of pyasn (MIT-License) which builds on other products with different lisenses. One of them (mrtd) uses a 4-Clause BSD license which might be incompatible to AGPL.
Do you know of alternatives to pyasn?
yes. We can replace it by a separate BGP table feed + a bot which queries this. See also the certtools/quagga-whois code.
Best Regards Dustin
-- dustin.demuth@intevation.de https://intevation.de/ OpenPGP key: B40D2EFF Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Intelmq-dev mailing list Intelmq-dev@lists.cert.at http://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev
On 01.04.2016 14:41, L. Aaron Kaplan wrote:
yes. We can replace it by a separate BGP table feed + a bot which queries this. See also the certtools/quagga-whois code.
I'm not a BGP/routing expert and I wonder what's the best way to deal with cases like this:
We are currently using Team Cymru's IP to ASN mapping service for our reports. Their service is afaik also based on BGP data and maps 31.7.176.0 to AS201011.
This is also what you get when querying riswhois.ripe.net: route: 31.7.176.0/20 origin: AS201011
However, there is a more specific /21 netblock registered with RIPE and RIPE Whois returns a different ASN for this IP:
inetnum: 31.7.176.0 - 31.7.191.255 [...] route: 31.7.176.0/21 origin: AS33891
- Thomas
CERT-Bund Incident Response & Malware Analysis Team
On 2016/04/15 16:04, Thomas Hungenberg th@cert-bund.de wrote:
On 01.04.2016 14:41, L. Aaron Kaplan wrote:
yes. We can replace it by a separate BGP table feed + a bot which queries this. See also the certtools/quagga-whois code.
I'm not a BGP/routing expert and I wonder what's the best way to deal with cases like this:
We are currently using Team Cymru's IP to ASN mapping service for our reports. Their service is afaik also based on BGP data and maps 31.7.176.0 to AS201011.
This is also what you get when querying riswhois.ripe.net: route: 31.7.176.0/20 origin: AS201011
I can't talk about the precision of Team Cymru's DB. However, the RIPE DB is about assignments whereas the BGP data / BGP routing tables of course is about current announcements. These might differ (though they should not ;-)
There is another way: run your own BGP full feed mirror and query it live: https://github.com/certtools/whois-quagga
Hope it helps, a.
However, there is a more specific /21 netblock registered with RIPE and RIPE Whois returns a different ASN for this IP:
inetnum: 31.7.176.0 - 31.7.191.255 [...] route: 31.7.176.0/21 origin: AS33891
- ThomasCERT-Bund Incident Response & Malware Analysis Team
Intelmq-dev mailing list Intelmq-dev@lists.cert.at http://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev
On 01.04.2016 13:57, Dustin Demuth wrote:
Dear all,
whilst packaging we've had a look at the licenses. Most things are ok, but there might be a problem with the asn_lookup expert.
It makes use of pyasn (MIT-License) which builds on other products with different lisenses. One of them (mrtd) uses a 4-Clause BSD license which might be incompatible to AGPL.
As I read it, pyasn can (optionally) parse files created by mrtd, but does not incorporate or link to the mrtd source code.
Thus I don't think we have a problem here.
otmar
Dear all,
I've had a look at this post again, and also opened an Issue for this
https://github.com/hadiasghari/pyasn/issues/25
Am Freitag 01 April 2016 16:03:12 schrieb Otmar Lendl:
As I read it, pyasn can (optionally) parse files created by mrtd, but does not incorporate or link to the mrtd source code.
Unfortunately it does incorporate the mrtd code: https://github.com/hadiasghari/pyasn/blob/master/pyasn/_radix/radix.c
As of now I'm in contact with the developer of PyASN, who contacted me in private. I hope we can move the discussion to a public list for the sake of transparency.
Let's see what we will find out in the next days.
BR Dustin