Opened 3 years ago

Closed 2 years ago

#17299 closed enhancement (fixed)

Standardize comment in dirauth-conf

Reported by: dgoulet Owned by:
Priority: Medium Milestone:
Component: Core Tor/DirAuth Version:
Severity: Normal Keywords:
Cc: micah, tom Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

After discussions in Berlin, I would like to propose a standard format for the comment of an entry(ies). Benefits are that we can validate the format of the file easily with a verifier script and also automatically cleanup on a regular basis the file of old entries with a simple script.

Furthermore, it makes it much more readable and traceable for each rules.

Format would look like this:

# Reported-by: Gargamel <gargamel@smurf.com>
# Date: Tue, 5 May 1987 20:45:57
# Time-Period: 3 months
# MessageID: <ID of first email on bad-relays@>
# Reason: <why was it blocked. add any relevant data about this>
#         [...] (as many line as we need for this)
# Fingerprints: FP1[,FP2,FP3,...]
AuthDirBadExit 0.0.0.0

Date: the UTC timestamp of when the bad relay was detected.

Time-Period: time period for which we keep blocking this entry. In this example, it would be OK to remove the entry on August 5th (3 months later).

Reason: description on why it was blocked. Can be multiple lines.

Fingerprints: [optional] fingerprint of the blocked relay (or list seperated by comma) if applicable. If we blacklist a whole network because we got 1000+ relays, we can omit it.

The rest is self explainable.

phw already uses a nice format in the latest commit, this just makes it more formal. I'll attach a small script to the ticket that we can at some point add to the repository that will print to the user the template with some defaults for which the user can only fill in the blanks.

Child Tickets

Attachments (1)

make-entry.py (8.0 KB) - added by dgoulet 3 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 3 years ago by micah

Cc: micah added

comment:2 Changed 3 years ago by atagar

I really like this idea and would be happy to add a DocTor check to notify of expired entries. Couple requests though...

  • Lets add a 'Name' or 'Summary' field so I know how to refer to a particular rule in the notifications.
  • Rather than 'Time-Period' lets have an expiration timestamp (that way I won't need to parse '1 month later' or other strings like that).

comment:3 Changed 3 years ago by phw

I like this too, thanks David! If we still want to make the badexit/invalid/reject part public, I wonder if the expiry field helps our adversaries.

Changed 3 years ago by dgoulet

Attachment: make-entry.py added

comment:4 Changed 3 years ago by dgoulet

Yes I also think so. This is maybe a good reason why this list shouldn't be public. Now, we can make it public and keep a seperated "database" for those expiry time that would not be too difficult but more engineering.

I'm attaching a python script I made that will allow us to easily add new entries that have the standard format and are validated. I propose we add it to dirauth-conf repository in maybe a "scripts/" or "tools/" directory so we can start using it and also *improve* it as needed for our needs.

Feedback *very* welcome!

comment:5 in reply to:  2 Changed 3 years ago by dgoulet

Replying to atagar:

I really like this idea and would be happy to add a DocTor check to notify of expired entries. Couple requests though...

  • Lets add a 'Name' or 'Summary' field so I know how to refer to a particular rule in the notifications.

I've added an "Identifier" field that hashes some stuff from the entry with some random so we can have a unique identifier for each rule. Very good idea.

  • Rather than 'Time-Period' lets have an expiration timestamp (that way I won't need to parse '1 month later' or other strings like that).

It's now "Expiry" field and it's only a number that is a number of days.

See make-entry.py attachement.

comment:6 Changed 3 years ago by cypherpunks

What if it was not reported by email? I can't/don't use email.

comment:7 Changed 3 years ago by cypherpunks

This feels like stuff that should be visible to dirauth operators and people specifically interested in bad relays, only.

comment:8 in reply to:  7 Changed 3 years ago by dgoulet

Replying to cypherpunks:

This feels like stuff that should be visible to dirauth operators and people specifically interested in bad relays, only.

I would advocate to broaden the number of people that have at least read access to the repository which could make sense to make it accessible to bad-relays@.

comment:9 Changed 3 years ago by atagar

It's now "Expiry" field and it's only a number that is a number of days.

I was suggesting an expiration timestamp, like...

# Subject Trotsky Sybil
# Expire 2016-01-01

Then this is the only field that would need to be consulted to give a notification saying "The entry for 'Trotsky Sybil' has expired'. Absolute times are a tad nicer to deal with.

comment:10 Changed 3 years ago by dgoulet

Did the change atagar. Here is a new version (I put it on people.tpo for now, easier to update :).

Forgot to mention, requirement for the script is "python3-netaddr" and only works with python 3 for now.

https://people.torproject.org/~dgoulet/volatile/make-entry.py

comment:11 in reply to:  10 ; Changed 3 years ago by phw

Severity: Normal

Replying to dgoulet:

Did the change atagar. Here is a new version (I put it on people.tpo for now, easier to update :).

Forgot to mention, requirement for the script is "python3-netaddr" and only works with python 3 for now.

https://people.torproject.org/~dgoulet/volatile/make-entry.py

Great work! Can we put this under version control somewhere?

comment:12 in reply to:  11 ; Changed 3 years ago by dgoulet

Replying to phw:

Replying to dgoulet:

Did the change atagar. Here is a new version (I put it on people.tpo for now, easier to update :).

Forgot to mention, requirement for the script is "python3-netaddr" and only works with python 3 for now.

https://people.torproject.org/~dgoulet/volatile/make-entry.py

Great work! Can we put this under version control somewhere?

Yes we should definitely! We could put it in dirauth-conf directory in a tools/ dir for instance? I would also like to add soon a script that goes over bad.conf and removes every entry that had expires. (Ease our life a bit).

comment:13 in reply to:  12 Changed 3 years ago by micah

Replying to dgoulet:

Yes we should definitely! We could put it in dirauth-conf directory in a tools/ dir for instance? I would also like to add soon a script that goes over bad.conf and removes every entry that had expires. (Ease our life a bit).

I think it makes sense to put it in the tools/ dir in dirauth-conf!

comment:14 Changed 3 years ago by tom

Cc: tom added

If the DirAuth configs do become public, I can integrate information into consensus-health also. (Number of expired entries, why does this relay have BadExit, etc)

comment:15 Changed 2 years ago by arma

Did we do the thing described in this ticket? All done?

comment:16 Changed 2 years ago by dgoulet

Resolution: fixed
Status: newclosed

Indeed, all done. It's in tools/ of dirauth-conf now and been used for almost a year now.

Note: See TracTickets for help on using tickets.