Skip to content
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

Closed
wants to merge 1 commit into from
Closed

Conversation

dralley
Copy link
Collaborator

@dralley dralley commented Mar 16, 2023

Remove the signature-meta feature because it's a bit superfluous

closes #105

📜 Checklist

  • Commits are cleanly separated and have useful messages
  • A changelog entry or entries has been added to CHANGELOG.md
  • Documentation is thorough
  • Test coverage is excellent and passes
  • Works when tests are run --all-features enabled

@dralley dralley requested a review from drahnr March 16, 2023 02:05
@dralley dralley force-pushed the payloaddigest branch 4 times, most recently from c4c67e0 to 9f0a3b2 Compare March 16, 2023 02:23
Copy link
Contributor

@drahnr drahnr left a 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.

@dralley dralley force-pushed the payloaddigest branch 2 times, most recently from ccd43ab to 10924b5 Compare March 17, 2023 00:47
@dralley
Copy link
Collaborator Author

dralley commented Mar 17, 2023

@drahnr Take another look, I removed [cfg(feature = "signature-pgp")] from everything not explicitly touching pgp

@dralley dralley requested a review from drahnr March 17, 2023 00:49
Remove the signature-meta feature because it's a bit superfluous

closes rpm-rs#105
Copy link
Contributor

@drahnr drahnr left a 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.

@drahnr
Copy link
Contributor

drahnr commented Mar 19, 2023

I'll comment in more detail at some point in the next few days

@dralley
Copy link
Collaborator Author

dralley commented Mar 27, 2023

@drahnr ^

@@ -389,7 +387,6 @@ impl RPMBuilder {
let mut header = Vec::with_capacity(128);
header_idx_tag.write(&mut header)?;

#[cfg(feature = "signature-meta")]
Copy link
Contributor

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")]
Copy link
Contributor

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.

Copy link
Collaborator Author

@dralley dralley Mar 28, 2023

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 the Signing 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 in signature-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.

https://github.com/rpm-rs/rpm/pull/106/files#diff-b82882f602be2cf2d09fd6546c2097235d9417da83223e9516b8eb783c6257ffR396

Copy link
Collaborator Author

@dralley dralley Mar 29, 2023

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")]
Copy link
Contributor

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)]
Copy link
Contributor

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.

Copy link
Collaborator Author

@dralley dralley Mar 28, 2023

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")]
Copy link
Contributor

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct 👍

@dralley
Copy link
Collaborator Author

dralley commented Mar 31, 2023

@drahnr How should I proceed? Would you like signature-meta returned to the few places noted or did my explanation make sense?

@drahnr
Copy link
Contributor

drahnr commented Mar 31, 2023

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

@drahnr drahnr mentioned this pull request Apr 1, 2023
@drahnr
Copy link
Contributor

drahnr commented Apr 14, 2023

Closing, #111 is merged and covers the same functionality, but does not interleave it with the signature logic but detaches it.

@drahnr drahnr closed this Apr 14, 2023
@dralley dralley deleted the payloaddigest branch April 15, 2023 12:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Package checksums are not calculated during build when "signature-meta" feature is disabled
2 participants