-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
always digest #111
always digest #111
Conversation
FYI, I'm working on an overhaul of the tests right now now, so it might be best to drop that commit to avoid conflicts - but I will try to introduce a similar split by the time I'm done with it. Work in progress here: #115 |
@drally please hold off, I'll complete these changes early next week |
Well, I was hoping to finish mine tomorrow or by the end of the weekend... Note that I'm talking exclusively about the tests and not the digest PR. It's separate. |
I don't, in general, like keeping tests that could (and ought to be) integration tests inside |
Copying 32 bytes is cheaper than creating a ptr/reference.
41159e2
to
eaf0eb6
Compare
@@ -136,17 +136,17 @@ where | |||
Ok(()) | |||
} | |||
|
|||
pub(crate) fn find_entry_or_err(&self, tag: &T) -> Result<&IndexEntry<T>, RPMError> { | |||
pub(crate) fn find_entry_or_err(&self, tag: T) -> Result<&IndexEntry<T>, RPMError> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this isn't your code, but find_entry_or_err
seems a little redundant on a function that returns a Result
. I don't see this pattern on any of the standard library (https://doc.rust-lang.org/std/index.html?search=or_err). Might be worth fixing up as part of this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With regards to this specific change - I think this makes the interface a little nicer if you're only comparing to "instances" of Tags (as per the tests). I'm assuming that Tags are not very big and the general use for this interface is to search for specific Tags.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tags are u32
s in disguise, hence there is no point in taking a reference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll leave the API as is, since my expectation on a find
would be to return an Option
, but this does return a Result
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, wrong account. Looks good :)
(I can't really comment on the design aspects here - they look reasonable though! The Rust I've already commented on.)
@drahnr I had asked for "split up tests" to be dropped : / |
I am sorry, I forgot about that. I would generally prefer if we could sync on any upcoming work, rather than fighting on changes to merged or skipped, but rather avoid competing changes in the first place if they become to cumbersome to do a |
@drahnr Since the commits got squashed, the commit |
@@ -142,12 +191,10 @@ impl RPMPackage { | |||
/// | |||
/// | |||
#[cfg(feature = "signature-meta")] | |||
pub fn verify_signature<V>(&self, verifier: V) -> Result<(), RPMError> | |||
pub fn verify_signature<V>(&self, verifier: V) -> Result<SignatureVerificationOutcome, RPMError> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@drahnr I'm confused by this. Nothing actually returns SignatureVerificationOutcome::Fail
so it doesn't seem useful? Even if it did, encoding an error condition in the success path feels very wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's correct, fix eta today
Ok(DigestVerificationOutcome::Match) | ||
} else { | ||
Ok(DigestVerificationOutcome::Mismatch) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A test for this would be good.
Like above though I'm confused about the error strategy. If I were to write some fairly intuitive code such as
pkg.verify_digest()?;
it effectively won't actually be checking the digests because we've created a separate feedback mechanisms, and we're not marking the return value #[must_use]
to force the user to check it. It feels like a footgun.
Also with this approach there is no way to tell which digest failed or get any additional context back? We already have a ValidationError
variant for signature mismatch, I'm just confused why we're doing something different for digests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rationale was, that the RPM format is fine, the signature just failed to verify. And the verfication might simply caused by a missing key.
But I think for the common usage pattern you're correct that it poses a footgun.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
VerificationError
could have subtypes potentially
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually there is KeyNotFound
error already https://github.com/rpm-rs/rpm/pull/122/files#diff-6ff19a1ff611f3835b5a025663cf4dec901ed914626f78847414836439bd1a79L77
} = RPMPackage::create_digests_from_readers( | ||
&mut header.as_slice(), | ||
header_and_content_cursor, | ||
)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Modern versions of RPM don't actually generate these digests, but they would still be needed for e.g. EL7 packages. Maybe in a year when it goes EOL we can ditch this code.
This function can only be used for the legacy digests though, because the modern ones (PAYLOADDIGEST, PAYLOADDIGESTALT which I am currently adding support for) go into the main header, which has already been generated at this point.
@dralley includes the part of your PR, some additional cleanups, and the direction of using a
fn verify_digest
explicitly, so the user can opt-in explicitly to have either or both checked. Thefn verify_digest
is not feature gated, while thefn verify_signature
is.I hope this clarifies the conversation had in #106
Potentially I'll complete this PR soon™