December 2025 - db-wg - mailman.ripe.net

Updated Migration Plan to Remove MD5 Hashed Passwords from the RIPE Database
by Edward Shryane 14 Jan '26

14 Jan '26

Dear colleagues, The RIPE NCC database team published an updated plan in January to deprecate MD5 hashed passwords by the end of 2025: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/NGCRQWJPF7MT24… Since then, we have been working towards this deadline: * Added support for API key and OAuth 2.0 authentication * Notified maintainers and removed inactive passwords in June (including any passwords not used since January 2024) * Notified maintainers by email who are actively using passwords in July, September, October and November * Added a warning to the database web query page that passwords are deprecated * Added a warning to Whois update responses that passwords are deprecated I presented at the DB-WG session at RIPE 91 that use of password authentication is still very high: 32% of all updates used password authentication, by about 150 maintainers. By last week, this has decreased to 17% of all updates by about 105 maintainers. There is still a risk that the database community may not be ready for the end of year deadline. Taking this into consideration, I propose the following updated plan for the end of year deadline: * At the beginning of January (e.g. Monday January 5th at midday CET), remove all passwords from the RIPE database, after notifying maintainers and the working group. * Allow maintainers to add a password back to their maintainer if they still really need to use one (e.g. for operational reasons). * In the following Whois release, around the end of January, remove support for passwords altogether, again after notifying maintainers and working group. This gives us a rollback plan in case there are maintainers that need some extra time, and still allows us to follow through with deprecating passwords. In the meantime, we will continue to monitor use of password authentication. We also want to hear from any maintainers who need assistance with the migration, we are happy to help. Please let us know your questions or comments. Regards Ed Shryane RIPE NCC

2 7

Last call for discussion regarding NWI-2 and NWI-17
by David Tatlisu 06 Jan '26

06 Jan '26

Hi Everybody, At RIPE 91 I talked about how we would like to cancel NWI-2 and NWI-17, which both concern some variation of historical data in the RIPE database. NWI-2 concerns lifting some arbitrary limitations in the retrieval of historical data, as well as allowing the retrieval of deleted objects which have not been re-created. NWI-17 is significantly more complex, as it centers around implementing the Database Requirements Task Force Recommendations [1], and I suggest three possibilities for the future of this NWI: 1. Try to move NWI-17 forward by requesting a GDPR compliance report from the NCC 1. Since the RIPE NCC is the data controller GDPR compliance is technically solely their responsibility 2. Try to move this NWI forward by reducing the problem stated in the Database Requirements Task Force Recommendations by removing the special case for researchers getting wider access to data 3. Cancel NWI-17 Considering the discussions about both NWIs have died down over the last years, I would suggest we cancel both NWIs while keeping the option to re-open them in case interest grows. With this, I would like to cancel both NWI-2 and NWI-17 on January 5th assuming the working group does not want to keep them open. Please keep in mind that I do understand that these NWIs have not been created for the fun of it, and have good reasons behind them, but lack of discussion around these NWIs even considering several attempts to rejuvenate them also tells a story. [1]: https://www.ripe.net/community/tf/rdb-requirements-tf/database-requirements… https://www.ripe.net/community/tf/rdb-requirements-tf/database-requirements… Me talking about them at RIPE91: https://ripe91.ripe.net/programme/meeting-plan/sessions/38/R7WC3F/ Thank you for your feedback. David Tatlisu, On behalf of the Database WG Chairs. --- To me, in a personal capacity, closing them would be a formality as they have not had active discussions over the last several years, making them unofficially but effectively cancelled already.

3 3

inverse search help?
by Hank Nussbacher 18 Dec '25

18 Dec '25

I forgot how to do an inverse search to find my ASN in as-sets. So Google AI tells me: Yet: hank@nocvm:~$ whois -h whois.ripe.net -i members as378 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See https://docs.db.ripe.net/terms-conditions.html % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. %ERROR:105: attribute is not searchable % % "members" is not an inverse searchable attribute. %ERROR:101: no entries found % % No entries found in source RIPE. % This query was served by the RIPE Database Query Service version 1.120 (DEXTER) What am I doing wrong? Thanks, Hank

6 6

Defining NWI-21
by David Tatlisu 16 Dec '25

16 Dec '25

Hi Everybody, Marco Schmidt started a thread discussing the addition of the "reg-nr:" attribute to organization objects. Summarizing it very briefly, it would make identifying legal entities easier, as their government-issued identification number would be available in the database. The Database team plans on including a URL to the responsible company register on the web frontend where available, while the WHOIS and RDAP will not include the URL. Marco already went through the effort of writing both a Problem Definition and a Solution Definition, which "fast-tracked" a few steps of the NWI process :p From what I was able to determine, the discussion on the working group did not lead to any change of either the Problem or Solution Definition. There were some concerns about potential privacy issues which, as far as I was able to tell, were able to be rectified to a sufficient degree as the new data is already public and potential edge-cases were brought to the attention of the RIPE-NCC. With this, I now declare consensus on the Problem Definition and have determined that this can continue using the NWI process. Please share any additional feedback for the Solution Definition until 22nd December. Considering the current state of the discussion, I think it's safe to say that the working group participants will have agreed on the Solution Definition after this date. With this, I thank all participants for their contributions to this NWI. Kind Regards David Tatlisu, On behalf of the Database WG Chairs. ### Copied from Marco's original e-Mail from 17th November Problem Statement: The RIPE Database should allow users to uniquely identify Internet Number Resource holders. Today, organisation objects linked to RIPE NCC co-maintained inetnum, inet6num, and aut-num objects include the validated legal organisation name and country code where the resource holder is legally registered. However, these attributes alone are not always sufficient to uniquely identify a legal entity, for three main reasons: 1. Identical names: In some jurisdictions, different companies can legally register with the same or very similar names. 2. Transliteration issues: In countries using non-Latin scripts, converting names from and into Latin characters can produce inconsistent or inaccurate results. 3. Data discrepancies: Differences between the validated legal information (org-name and country) and the contact details maintained by the resource holder (for example, a postal address in another country) can create confusion and make identification more difficult. Solution Definition: Introduce a new reg-nr: attribute for RIPE NCC co-maintained organisation objects, containing verified company registration numbers issued by national authorities. The RIPE NCC already holds this information for ~99% of resource holders that are legal entities. Publishing a unique and verifiable registration number will significantly improve the ability of RIPE Database users to accurately identify resource holders and cross-check them in national company registries. Only publicly available registration numbers of legal entities will be published. Natural persons remain explicitly out of scope.

3 2