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

Provide a way for the windows signing service to control name and url parameters of the attached signature #503

Open
netomi opened this issue Jul 24, 2024 · 4 comments

Comments

@netomi
Copy link
Contributor

netomi commented Jul 24, 2024

Currently, the name and url used for signing an executable is hard-coded in the service.

That means all executables signed with the service will have the same information which currently is set to the following:

      windows.jsign.description=Eclipse Foundation, Inc.
      windows.jsign.url=http://www.eclipse.org/

Now I am not aware of any reasons to do so, but I find this kind of odd. Shouldnt we support setting this information in the request as well?

@mbarbero ?

@mbarbero
Copy link
Member

You mean that this is not customizable by the caller of the service, correct? If this is only metadata and does not need to match the CN of the certificate, then I'm not opposed to it.

@netomi
Copy link
Contributor Author

netomi commented Jul 25, 2024

indeed, atm the caller of the service has no control over that parameters and always the fixed values are taken for every executable that is signed. I dont know what is displayed as information in Windows as even osslsigncode does not show that info surprisingly, so a second opinion on that would be good. But I assume that this is information that is specific to the executable that is signed, so having fixed values for everything is a bit couter intuitive imho.

@mbarbero
Copy link
Member

Agreed.

@merks
Copy link

merks commented Jul 25, 2024

Thanks for being proactive.

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

No branches or pull requests

3 participants