-
Notifications
You must be signed in to change notification settings - Fork 26
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 create package digests #106
Conversation
c4c67e0
to
9f0a3b2
Compare
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.
See the inline comment. I think we should decouple signature creation from the signing. Hence I don't think combining pgp
with the API of signing/verification is the right approach.
ccd43ab
to
10924b5
Compare
@drahnr Take another look, I removed |
Remove the signature-meta feature because it's a bit superfluous closes rpm-rs#105
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.
It's not in going into the direction I was thinking. Why change all the feature flags regarding signatures? I'd have expected splitting the hash/checksum creation from the whole signature creation logic, which does not need any changes on the feature flags side.
I'll comment in more detail at some point in the next few days |
@drahnr ^ |
@@ -389,7 +387,6 @@ impl RPMBuilder { | |||
let mut header = Vec::with_capacity(128); | |||
header_idx_tag.write(&mut header)?; | |||
|
|||
#[cfg(feature = "signature-meta")] |
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.
Yes, we should always build this, so removing the signature-meta tag here is correct.
@@ -422,7 +417,6 @@ impl RPMBuilder { | |||
/// use an external signer to sing and build | |||
/// | |||
/// See `signature::Signing` for more details. | |||
#[cfg(feature = "signature-meta")] |
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.
This is where I disagree. build_and_sign
is user visible API and should not be usable for skipping signatures. Imho build
should also create the header, but not sign it.
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.
This is where I disagree.
build_and_sign
is user visible API and should not be usable for skipping signatures.
What do you mean by "not be usable for skipping signatures"?
My thought process is this:
- It's possible for users to sign packages without using
signature-pgp
, because they can create their own implementer of theSigning
trait - It's not possible for users to use this API without providing an implementor of the
Signing
trait because it's a non-optional argument - it's not a step they can skip signature-meta
doesn't provide much value because the amount of code you skip by putting it behind a feature is minimal. For most users they will want the concrete implementations insignature-pgp
, but there's not really harm in having functions which use those generic APIs be available always, because it's conceivable that a user could still use them.
I guess I don't feel that strongly about it, so if you do strongly feel that signature-meta
should be kept then we can keep it. I just don't see it as having much practical value separate from conceptual structural value.
Imho
build
should also create the header, but not sign it.
That's what it currently does (in this PR)? It produces a signature header and populates it with digests, but not the signatures.
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.
On a separate note though, we could almost do away with build_and_sign()
if we take RPMPackage::sign()
and make it take and return self
instead of &mut self
and ()
.
That way you could write this chain, which ought to be equivalent to build_and_sign()
.
let pkg = RpmBuilder::new(....)
[....]
.build()
.sign(signer);
Or at least reimplement the former in terms of the latter to avoid the amount of code duplication we currently have between the 3 functions. Though we could address that in other ways, too.
@@ -471,7 +465,6 @@ impl RPMBuilder { | |||
} | |||
|
|||
/// use prepared data but make sure the signatures are | |||
#[cfg(feature = "signature-meta")] |
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.
✔️
@@ -163,7 +163,7 @@ where | |||
.ok_or_else(|| RPMError::TagNotFound(tag.to_string())) | |||
} | |||
|
|||
#[cfg(feature = "signature-meta")] | |||
#[allow(unused)] |
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.
It shouldn't be unused, either it's required in meta or any of the the given concrete signer implementations which should end up in a cfg(any(..))
annotation or be deleted.
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 reason it's marked allow(unused)
is that it's marked pub(crate)
and there are no internal users except for the signature verification code, which isn't always enabled. So we can't outright delete it.
However, this is pretty generic functionality (not actually feature-specific), and I can't think of a great reason to not allow reading arbitrary tags so long as we make it clear that it's not the preferred way when methods exist on RpmPackageMetadata
. And I imagine we won't want to write specific functions for every single possible tag including the obscure ones that some crazy person might still want to read.
So probably we should just make the methods for reading header tags public.
@@ -31,7 +31,7 @@ fn cargo_manifest_dir() -> std::path::PathBuf { | |||
std::path::PathBuf::from(env!("CARGO_MANIFEST_DIR")) | |||
} | |||
|
|||
#[cfg(feature = "signature-meta")] | |||
#[cfg(feature = "signature-pgp")] |
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.
Doesn't require the pgp signer, the API is enough.
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.
Correct 👍
@drahnr How should I proceed? Would you like |
As you can imagine from my latency, I didn't get around to suggest a viable path, but I do have an intuition what needs to be done. I hope I can create a draft PR really soon |
Closing, #111 is merged and covers the same functionality, but does not interleave it with the signature logic but detaches it. |
Remove the signature-meta feature because it's a bit superfluous
closes #105
📜 Checklist
--all-features
enabled