search

sandwichfarm / nostr-watch

nostr registry and monitor web-client
https://nostr.watch
MIT License
180 stars 483 forks source link

Add Nostream Version Attribute [Feature Request] #395

Closed alltheseas closed 11 months ago

alltheseas commented 1 year ago

Is your feature request related to a problem? Please describe. I want to easily find what version of Nostream a relay is running. I am not aware of a solution for this. There can be security risks in running Nostream versions that are not up to date, and I want to avoid the vulnerable relays.

Describe the solution you'd like

User Story

As an advanced relay user who is performing security research on relays, I want to know which Nostream version is being run by which relay, so that I can adjust my relay preferences accordingly.

Acceptance Criteria

  1. User has method to see a relay's Nostream version
  2. User can "aggregate" according to a certain Nostream version (for instace, the latest nostr version 1.22.2)

Describe alternatives you've considered Don't do anything.

Additional context See Cameri security patch announcement https://damus.io/note1z9zvwfdfqnnz9z02faxucc7pyp483mh8fq8ew76j0p8xswzdxdzqdw07ek

ATTENTION ALL NOSTREAM RELAY OPERATORS: CRITCAL SECURITY VULNERABILITY FIX RELEASED IN THIS VERSION. Please update your Nostream relay to 1.22.2 ASAP. I can’t reach to each Nostream relay operator individually cause y’all don’t set your pubkey on your settings. Details about the vulnerability will be disclosed soon. A patch version of nostream has been released. Current version is 1.22.2 1.22.2 (2023-02-10) Bug Fixes (Vulnerability not included here)

  • instructions to run locally
  • upgrade axios from 1.2.2 to 1.2.3
  • upgrade knex from 2.4.0 to 2.4.1 Security vulnerability reported by Peter Thanks Peter!
dskvr commented 1 year ago

I will at no point be giving special treatment to specific relay softwares, results in too much bloat. However, this is NIP-11, so would be better worded as "show version for relays".

That said, the version attribute for relays is already displayed for relays with NIP-11 on the relay's page.

Screen Shot 2023-02-12 at 4 44 18 PM

Where are you asking for this to be displayed? In a table column? Are you asking for this to be a filterable attribute?

dskvr commented 1 year ago

@alltheseas

Where are you asking for this to be displayed? In a table column? Are you asking for this to be a filterable attribute?

alltheseas commented 1 year ago

Where are you asking for this to be displayed? In a table column? Are you asking for this to be a filterable attribute?

I was suggesting both added in table column, and filterable.

I will at no point be giving special treatment to specific relay softwares, results in too much bloat. However, this is NIP-11, so would be better worded as "show version for relays".

This makes sense. I was assuming all relays ran the same software/OS.

Re-reading the user story I wrote, the version is a means to an end. The job-to-be-done here is "is this relay secure". So if a relay runs with a known unsecure version of relay OS/software (for instance anything prior to cameri nostr 1.22.2), there should be a secure/insecure column displayed + attribute.

What do you think @dskvr ?

Updated

User Story

As an advanced relay user who is performing security research on relays, I want to know which if a particular relay is running insecure software, so that I can adjust my relay preferences as not to use insecure relays.

Acceptance Criteria

User has method to see if relay is insecure.

dskvr commented 1 year ago

Yes, I think this is an excellent idea.

There are a number of issues at present that make this difficult

  1. Because the "list of versions" is different for each Software, it requires a really solid user interface solution, as obviously, the version list would only be visible when filtering by a relay, and the version list would be unique to each relay.
  2. Presently the filter data is populated is via a job (ttop right corner), this was a bit of a hack to get it working. I planned on refactoring this around 0.4, which would take into account more filter requirements, and be compatible with mobile. It's not a small task.
  3. If I ammended to the hack, and generated a version list in the same job, instead of when the filter is clicked, I am bloating the memory further, and I'm already riding that line quitte dangerously as it is.

0.4 will include a number of optimizations and refactors, and implementing this feature during such an exercise would likely prove more fruitful, with less wasted time/energy.

Now, when it comes to the goal "User has method to see if relay is insecure," it would be interesting to figure out a standard where relay operators can use nostr to post advisories for specific versions, and then those advisories appear on nostr.watch. This would be much easier to implement, and doesn't require a user to know before hand that a version is insecure, instead, they would just see an advisory from the relay software author.

there are some minor chores there:

  1. Maintain a regisry of public keys -> relay software authors. Likely a yaml file similar tot relays.yaml but more verbose. Would need to include:
    • org/software name as key
    • pubkey object member where hex public key is defined.
    • relay that indicates an author's home relay.
  2. Subscribe to notes containing identified tags [#t] from specific pubkeys (as defined in yaml above) and...
    • display on single page
    • display an icon that indicattes "advisory" in table results