I am trying to install Apache Lucene 5.3.0 (from source). The mirror sites provide lucene-5.3.0-src.tgz and lucene-5.3.0-src.tgz.asc (the signature file), however the latter is using RSA key ID 3FCFDB3E which is not contained in the KEYS file (which is also provided).
$ gpg --verify ./lucene-5.3.0-src.tgz.asc
gpg: assuming signed data in `./lucene-5.3.0-src.tgz'
gpg: Signature made 2015-08-17T13:35:34 CEST using RSA key ID 3FCFDB3E
gpg: Can't check signature: public key not found
The issue seems to be affecting multiple sites. What should the fingerprint be? Why is the key not included in the KEYS file?
It seems that the key of Paul Noble is what you're looking for, having fingerprint
CFCE 5FBB 920C 3C74 5CEE E084 C38F F5EC 3FCF DB3E
The key is rather new (a bunch of weeks old).
You cannot be really sure whether he's permitted to release for Apache Lucene, nor that the key actually belongs to him.
A short Google survey at least indicates several contributions to free software, and also the Linux kernel, but this should not be considered trustworthy without further analysis. There are also no incoming certifications that could be used to verify the key through the web of trust.
I'd recommend to get in touch with Apache, possibly on the Lucene mailing list, and query the developers how to verify the release based on what trust assumptions. And indicate there's something wrong which they should change (eg., include the key in the KEYS file).
the policies around where KEYS files are "published" for the lucene project is kind of confusing, compounded by the use of id.apache.org -> people.apache.org and it's automatic generation of a KEYS file for each project committee based on their current keys. some backstory here...
https://issues.apache.org/jira/browse/LUCENE-5143
The current policy is that each new Lucene/Solr release publishes a snapshot of all the current keys, so for 5.3.0 that would be here...
https://www.apache.org/dist/lucene/java/5.3.0/KEYS
...but the older "non version specific" keys files are still available - notably for verifying older versions of software in the archives that may predate the current policy.
You can always see the list of all "active" keys for a given apache project/user using http://people.apache.org/keys/
http://people.apache.org/keys/group/lucene.asc
Related
I'm working on creating a local image registry for an OKD installation by following along with this Medium article which assumes the creation of
the self-sign CA, server certificate with both the short and fully
qualified hostname of this VM
It calls for
the CA cert, server cert, server key saved as myca.pem,
registry.pem, registry-key.pem
I'm pretty new to certs so I was following the guidance of this article and using cfssl (as recommended by the former article) for generating those. I've gotten through generating and signing the "Intermediate CA". I'm a little unclear on where and how to generate the specific certs the former article requires. I'd really appreciate some clarifications or guidance, if possible, on the following issues.
I believe the ca.pem generated in the first "CA Authority" process in the
latter article is the equivalent of the myca.pem file mentioned in
the former article, but with a different name. Is this the case?
I am unclear where exactly the registry.pem and registry-key.pem
files are generated. Are these just certificates generated using the
"server" profile and assigned the name "registry"? Are they a
completely separate profile I should be adding to the
cfssl.json file? Are they neither?
In whichever case, are there any additional usages I need in the
cfssl.json file or additional config files I need to create in order for it to be suitable for an image registry? Do I
still need to create the additional "host certificate config file" mentioned in
the latter article?
I have tried absorbing as much information about ssl certificates as I could but so far I am unfortunately not finding anything that clears up the specific questions I have. I am sure this is probably simpler than I realize, so any help clarifying what's needed here would be profoundly appreciated. Thanks very much.
I was able to figure this all out. Here are the answers to my three questions:
This was the correct assumption.
These are generated using the "server" profile and given whichever name I choose.
I had to create the additional host certificate config file and point the CN in that file to my local fully qualified domain name. This config file was then used as an argument for generating the certificates.
Does anyone know how to transition authentications on NTP? I've done copious amounts of research, none being fruitful. For example, NTP currently using MD5, how do you move over to SHA1?
NTP if compiled along with OPENSSL libraries, then NTP uses OPENSSL libraries for cryptographic operations.
Then you can use different types of message digest algorithms supported by OPENSSL. This is a link which explains configuring ntp key file.
The key file where the keys will be present should be added to the /etc/ntp.conf file.
The keys to be used for generating the digest will be present under
/etc/ntp/keys . This path should be added to /etc/ntp.conf file to specify that this is the keys file.
The structure of the entry in the file will be
This is an example of the keys file
You can mention the keytype as "SHA1" to use SHA1 authentication.
Further details about the length of the digest and keys can be found here:
https://www.eecis.udel.edu/~mills/ntp/html/authentic.html
You can have multiple keys one next to the other.
SO:
first add the new key everywhere
delete the old key once it's added everywhere.
Most tools I download have a SHASUM or MD5 file listed somewhere to checksum files once download.
However, I downloaded Zookeeper recently and was having a heck of a time finding the checksums for it. I could create them myself, but would also like to verify against a public checksum.
Might they also sign releases? How would I go about verifying with GPG.
No, the Apache Foundation does not maintain a centralized checksum repository for binary distributions for any Apache project, nor do they mandate it. Same goes for a signing certificate. Both of these are project-level concerns and must be requested per-project through their project-specific issue tracker.
I have created my own key (public/private) via keychain access.
But my company already have created a provisioning profile and developer certificate,which i downloaded (after logging) and installed it in my Xcode and iPhone as well.
But when i try to run on iPhone,it says "There are no valid certificate/private key pairs in the default keychain".
I have also set bundle identifier name correctly in info.plist,but what am i doing wrong?
Is it that i should somehow add my own mac key pairs to somewhere as to match it since it is already created by company?
Could anyone help or suggest where m i going wrong,i have searched forums they all are simply not matching my problem and misleading other ways.
Thankx in advance.
You need the private key for the developer certificate that you have downloaded. The error "There are no valid certificate/private key pairs in the default keychain" means you don't have the private key.
You say "my company already have created a [...] developer certificate", which sounds like they have created a developer certificate for you. If that is the case, they need to send you the private key because you won't have this by default.
Generally it should be up to each individual developer to make a certificate signing request and gerenate the development certificate in the provisioning portal. There's no reason for the company to do that for you.
I'd like to understand some of the best practices with respect to code signing. We have an Eclipse-based application and think it would be appropriate to sign our plug-ins. This raised a lot of questions:
Can/Should the private key be in
source control?
Should we sign the code as part of
our nightly build process or as part
of our release process?
Should the code be signed
automatically, or is there a reason
why that should be a manual step?
My inclination is to say, "Yes", "Nightly", and "Automatically", but I could see an argument for only signing the release products. I might even make the argument that SQA should sign the code after they have verified it, although that would really mess with our release process.
How do other people manage this?
It depends on how secure you want your private key to be, it might not be something that you want a temporary employee with source access to have full access to.
At my work, we do the following:
"Test sign" binaries as part of our daily builds with a checked in key. This requires a test root certificate to be on machines in order to trust the binaries, but they will not be trusted if the bits are deployed outside the company.
Weekly (and for external releases), we sign with the real key. This is done via a separate, somewhat manual process. Only a few people have access to the key to sign the product.
I can tell you how I've see this being done in a big corp. Individual developers could build the code, but they could not sign it. That would be a private build. Contiguos integration machine would drop nightly builds signed with a key stored on the build machine keystore, which would be a test key signed by a corporate certificate authority (ie. a key trusted only within the corp). The official build could be signed only by controlled machines with the official, global trusted authority signed, signature key stored in hardware modules in controled access room.
The idea is that a private key should realy have only one copy in the world (at most one extra for escrow). The whole value of the key is derived from its privacy, not from anything else. The moment is available to your entire org, is as good as putting it out on pirate bay.