<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/crates/tor-geoip/data, branch arti-v2.2.0</title>
<subtitle>mirror of https://gitlab.torproject.org/tpo/core/arti
</subtitle>
<id>http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.2.0</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.2.0'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2026-03-19T11:31:08Z</updated>
<entry>
<title>tor-geoip: Update geoip manually</title>
<updated>2026-03-19T11:31:08Z</updated>
<author>
<name>Clara Engler</name>
<email>cve@cve.cx</email>
</author>
<published>2026-03-19T11:31:08Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=92c997ec593ffd8471d8a7fe0d6e4f937f14c839'/>
<id>urn:sha1:92c997ec593ffd8471d8a7fe0d6e4f937f14c839</id>
<content type='text'>
This commit updates the geoip database manually using the infrastructure
from the Tor repository, mainly because the database has last been
refreshed about 3 years ago.

Of course we should embed this into the Arti release process, but
because the location database format is non-trivial, this might take a
bit longer to implement and in the VPN project we are currently facing
bugs that might be related to an outdated geoip database.
</content>
</entry>
<entry>
<title>tor-geoip: Add new crate with GeoIP database functionality</title>
<updated>2023-06-20T15:57:58Z</updated>
<author>
<name>eta</name>
<email>tor@eta.st</email>
</author>
<published>2023-06-13T14:27:14Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=d5632eacb2b0c03e6f250f6fbe435d921dea4f8e'/>
<id>urn:sha1:d5632eacb2b0c03e6f250f6fbe435d921dea4f8e</id>
<content type='text'>
- This adds a new crate, `tor-geoip`, which can parse and perform
  lookups in the GeoIP database C-tor already uses (generated by a
  maintenance utility in the C-tor codebase).
- We embed a copy of C-tor's databases with the crate and use
  `include_str!` to ship them with the binary, bloating its size
  somewhat.
  - This does, however, solve the problem of figuring out how to
    distribute these.
  - The plan is to gate this functionality behind a feature flag anyway,
    so the cost should be nil unless explicitly opted into.

Part of tpo/core/onionmasq#47.
</content>
</entry>
</feed>
