JAR signature verification #1

Closed
opened 2024-09-22 13:13:04 +02:00 by Minecon724 · 1 comment
Owner
  • The signature should probably be hardcoded (but that would of course be abstract so up to implementation)
  • I think the JAR is first downloaded to a temp directory, so it should be verified there before moving to destination
    • or verify it in place and ask to keep
- The signature should probably be hardcoded (but that would of course be abstract so up to implementation) - I think the JAR is first downloaded to a temp directory, so it should be verified there before moving to destination - or verify it in place and ask to keep
Author
Owner

A way of changing signatures is also needed. We could sign a JAR with the old signature and add another one for future updates, but what about the future updates? We can't bundle every signature ever used.

I would say make another file with public keys and max supported versions

A way of changing signatures is also needed. We could sign a JAR with the old signature and add another one for future updates, but what about the future updates? We can't bundle every signature ever used. I would say make another file with public keys and max supported versions
Minecon724 added the
enhancement
label 2024-10-27 16:06:18 +01:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Minecon724/jarupdater#1
No description provided.