Here we go. I added the list of fingerprints for April 2021. I plan to
keep adding fingerprints monthly on the same wiki page[3], as we find
them in attacks.
suggestion for an improvement to this process so it will become more accurate/complete (example: May 2021 is incomplete)
and continue to work even a few months or years later
and is more automation/machine readable friendly than the current approach
- perform rejections in monthly files (files are included in the dir auth config)
YYYY-MM
- have a monthly cronjob that copies and pushes the priors month file into a public git repository
Here we go. I added the list of fingerprints for April 2021. I plan to
keep adding fingerprints monthly on the same wiki page[3], as we find
them in attacks.
suggestion for an improvement to this process so it will become more accurate/complete (example: May 2021 is incomplete)
Could you elaborate on why you think May 2021 is incomplete and how to fix that?
and continue to work even a few months or years later
and is more automation/machine readable friendly than the current approach
- perform rejections in monthly files (files are included in the dir auth config)
YYYY-MM
Hrm, maybe. I am not sure. One thing that makes things complicated is that not all rejections are attacks in the sense we mentioned in the wiki, so we would suddenly need to track those cases in different files it seems.
- have a monthly cronjob that copies and pushes the priors month file into a public git repository
The wiki is essentially a public git repository. I am not sure what another public git repository would give us.
The wiki is essentially a public git repository. I am not sure what
another public git repository would give us.
it would give users of these lists the possibility to consume it
in a much more trivial way without having understand the
semantics of the wiki page
curl https://gitlab…/$lastmonth-rejection-file
Right. I was for some reason under the assumption we could get away by just linking to your mail. But you are correct, we should do better here. So, I went over our May rejections again and updated the wiki page with the ones I think were missing.[1] Thanks!
The wiki is essentially a public git repository. I am not sure what
another public git repository would give us.
it would give users of these lists the possibility to consume it
in a much more trivial way without having understand the
semantics of the wiki page
curl https://gitlab…/$lastmonth-rejection-file
Fair enough. I am not sure yet how we'll make those improvements, but I've filed a ticket[2] at least to not forget about it. My current plan is to tackle that task while re-doing our bad-relay related tooling, which is supposed to start Q1 2022.
Georg
[1] I included an additional fingerprint that I missed while I was at it, as our tooling for that part is obviously not great yet.