For one my school projects I must build a CA and run various scenarios one of which is to distribute a Certificate Revocation List. The problem is that EasyRsa has no obvious functionality to tweak in order to specify a URI for a distribution point attached to the signed certificate.
Any ideas please since neither the official repo of EasyRsa on gitHub provides a solution nor OpenSSL is preferrable (I can't start over again :-))?
Related
The project I'm working on currently deploys our private node packages via github packages. Our current workflow is for each developer to create and maintain their own personal access token, and then we use a central account's PAT for automation in AWS.
I was wondering if it's possible to authenticate with github packages without the use of Actions or PAT's?
As of 2022-07-30
No, it is not possible to use github packages without a personal access token (PAT):
It is not possible to upload without a PAT (which makes sense as it prevents random people to upload binaries to your package repo);
It is not possible to download without a PAT (not even publicly available packages can be used);
As early as 2019-10-20, people have requested github to remove PATs as a requirement for mainly downloading public packages.
The idea is that users of libraries should not need to have a github account to access a developer's package.
Sadly, the request for pat-less package downloads was not granted by Github to this day.
If you want a package registry without a hassle, it might be wise to look for other registries, such as MavenCentral or JitPack (not necessarily meant for node packages),
or host a service yourself.
I even had to link a cached webpage, as the original question has been removed from Github community along with a bunch of related questions.
Another question on github, stating pat-less access to packages is still on the roadmap for "fall 2021" is here.
I could not find what the current status of this feature is.
Edit: It is possible to download binaries without a PAT for public repositories using jitpack.io. Jitpack builds the given jar/aar on their servers.
You can add jitpack as a repository to your build system, and use the jitpack-specified URL to reference releases, branches, or specific commits.
Sadly, there is no way to refer to packages (yet).
However, this system allows your users to use your code without needing PATs nor a Github account.
I'd like to offer an alternative.
You may use a Gradle plugin of mine (magik, I was exactly in your shoes) to easier the consumption of artifacts from your Github Packages for Gradle clients.
It require you to save your read-only PAT on the repo itself, so that the users don't have to deal with any authentication (apart using the plugin above mentioned)
I am working on an Android project. I have a few files under version control that git-crypt encrypt them for me. The content of some of them is important to be decrypted before running the build process.
I have no problem at all with building the project on my laptop. The problem is on the the CI side. When I push the code to the Origin, the pipeline (I am using Azure) triggers a pipeline and after a few seconds, the build fails. That's because the build system is looking for the information I have in keys.properties file and it's encrypted.
Based on my understanding, git-crypt uses public/private keys in order to encrypt/decrypt files. The public key is already under the version control, root/.git-crypt/keys/default/0/7F64F6C566153F29E4D9D44070C2A1QW029CE338.gpg. Therefore, I think I need to move the private key somewhere. Am I right? If I am right then my question is where to put it? Is it still under the root of the computer (macOS Image/VM on CI) or I can put it under the root of the project?
Note: Azure lets me upload secure files under its Libraries and then I am able to reference it from the azure-piplines.yaml file.
where to put it?
Based on my understanding on git-crypt and azure devops, compare with storing the private key in root of PC, I'd suggest you put it under the root of project.
Because if you store it at root of PC, it would has no trouble while you run the pipeline with Private agent. BUT, what the issue is if someone using Hosted agent but the private key is in local. As you know, Hosted agent is the one which located at cloud, and it is loaded very dynamically. So, it's hard to get the private key from local computer.
In one word, keeping it in the repository remove the hassle of storing it somewhere else and using it between developers.
However, above is just the suggest choice between store at root of PC and store at root of project.
Although, it would much convenient if put the private key into the root of project.
But on personal suggestion and info security, I strongly stand by the method that you mentioned at last: Store the private key in Library, and reference it during the build/release. Azure DevOps library store the secrets in a safe way and use them as and when needed without making it visible to anyone.
When creating a PowerShell module (or individual scripts, for that matter), if you must digitally sign them to comply with the defined ExecutionPolicy, should you commit the digitally signed files/scripts to source control? Or should signing the files/scripts be a step in the deployment process?
Signing should be a step in the deployment process. While signing during development is technically possible, you don't have any benefit from it, but add a bunch of lines of code to every commit.
Our dev servers at work currently can't reach nuget.org because of concerns about the safety of packages. Is it possible to apply a url rule / filter to a firewall that would allow access only to those packages with a "verified package owner"?
That's not possible with the server at this point.
There's no APIs that would allow you to query whether a package has a verified owner or not.
Additionally, the clients will hit so many different endpoints that it'd be very to make them all accessible.
You'd need to whitelist almost all packages likely.
There is some work on the clients being done to cover your scenario though.
Along side with package signing, a new client policies is being worked on.
That would allow you only to accept packages from certain package authors/feeds.
An alternative in the short-term would be to use a mirroring feed that everyone in the company uses.
That mirroring feed would only contain a set of whitelisted packages.
I followed instruction to generate a development APNS certificate and I am able to send the push notification successfully to my iPhone. Our application would be deployed on premise in customer environment, so I am looking for what instruction I should give customer to generate the APNS production certificate. Based on my search at this point, it is all about MDM APNS certificate generation and here is from Apple MDM web site:
1.Contact your MDM vendor to request a signed Certificate Signing Request (CSR). Your vendor will sign a CSR and deliver it to you.
2.Once you have a signed CSR from your vendor, visit identity.apple.com/pushcert and sign in with a verified Apple ID.
3.Click "Create a Certificate” and agree to the Terms of Use.
4.Select your signed CSR and click upload. After a moment, your certificate will be available for download.
5.This certificate can now be uploaded to your MDM server for use with the Apple Push Notification service.
However we don't want to be a MDM vendor, we just want to send push notification from server application to our iOS app which would be used by customer.
So do we have other choices? Or should we just package our production certificate with our solution to deploy in customer env? Somehow I didn't find information on internet for my case.
Since no one is answering, I am answering myself.
Based on this link Multiple Servers Connecting to APNS with same SSL certificate, we just need to distribute our production APNS certificate to customer. I guess we would need to update the production certificate on customer site when it is about to expire. By the way, it is also possible to have different production APNS certificates for different customer see link, I guess challenge would be how to manage those certificates when there are a lot.
It is highly welcome for any comments if you have experience in this area.