Is there a build/compile flag for kubernetes v1.14 to only build for signature verification and not signing? I have an embedded system acting as a kubelet that justs needs to verify a signature. I'm getting error saying, kubelet[289]: remote_image.go:113] PullImage "quay.registry/reponame/podman-test:latest" from image service failed: rpc error: code = Unknown desc = Source image rejected: Invalid crypto engine which indicates that kubernetes is missing external dependencies for signing.
I've tried adding:
-tags "containers_image_openpgp " similar to related issue here:
https://github.com/containers/skopeo/issues/660
My current build command is
make generated_files KUBE_BUILD_PLATFORMS="${HOST_GOOS}/${BUILD_GOARCH}"; make cross KUBE_BUILD_PLATFORMS=${GOOS}/${GOARCH}
The error is coming from GPG. Make sure your device has gpg or gpgv command in PATH and that signature verification with gpg command works.
gpgv is a stripped-down verification-only command that you could use, and Kubernetes supports it. Also, GPG has a ton of compile-time parameters to enable/disable parts of it, you can strip it down once you get it working.
If you find GPG too bloated or have a hard time getting it to work, you can try using https://sequoia-pgp.org/ which compiles to a statically linked binary without external dependencies. You will have to translate calls to gpg command into calls to sqv, but their CLI interfaces are really similar so it should be easy to do with a shell script, or whatever language your embedded platform supports.
Related
I'm having a strange issue when running a flutter app in a nix-shell (with an FHS environment).
Specifically, the app throws a CERTIFICATE_VERIFY_FAILED: unable to get local issuer certificate(handshake.cc:393).
(Some history in this post, which was never really solved.)
The https address I am contacting is LetsEncrypt signed, and works for all other clients, also e.g. with curl executed in the same nix-shell. (So this other issue doesn't provide valid solutions for the issue, because the case is different.)
So the question: where does the default flutter https-connection instance look for the system's ca-bundle.crt if apparently not under /etc/ssl/certs/ca-bundle.crt.
It also apparently doesn't use the SSL_CERT_FILE, at least setting it to a valid bundle location doesn't have any effect.
(Obviously one could put some explicit cert-loading functionality in the flutter app e.g. like suggested here, but that should be beside the point, since sensible system defaults should work out of the box.)
I am trying deploy and verify a contract using brownie on avalanche testnet.
The contract deploys and verifies fine on kovan. It deploys on avalanche testnet but I cannot get it verified.
The default brownie does not come with an explorer for avax testnet(kept getting explorer error) so I tried to add it.
I have tried variations of the testnet.snowtrace.io and they all give connection error except:
https://testnet.snowtrace.io/api - gives valueerror: error
I am using export SNOWTRACE_TOKEN= as per the documentation for avalanche and obtained an API key from https://snowtrace.io
Any idea IF and how this can be accomplished?
this does not seem to work on avax-test, using manual workaround so far ...
https://github.com/eth-brownie/brownie/issues/1417
Actually by default brownie "avax-test" network doesn't have set explorer field, So we have to set it manually by running below command,
brownie networks modify avax-test explorer=https://api-testnet.snowtrace.io/api
And you will able to verify contract.
Don't forget to add env variable,
SNOWTRACE_TOKEN=YOUR_TOKEN
A team I'm working with, has created a NAS Docker container. The Dockerfile uses FROM synadia/nats-account-server:0.8.4 and installs NSC using curl -L https://raw.githubusercontent.com/nats-io/nsc/master/install.py | python. When NAS is run in the Docker container, it is given a path to a server.conf file that contains operatorjwtpath: "/nsc/accounts/nats/OperatorName/OperatorName.jwt".
The problem is, that when I generate the operator on my PC using nsc add operator -i and when I run the Docker container on AWS Fargate and mount the JWT file to the appropriate folder using an AWS EFS filesystem, the container crashes and shows the error unexpected "ed25519-nkey" algorithm.
According to the NATS basics page, the algorithm that should be used is "alg": "ed25519". But when I generated the JWT and decoded it on this site, I see that what's being used is "alg": "ed25519-nkey".
So what is going on here? I can't find any specific info about an algorithm that has the "nkey" appended to its name. This is the default JWT that's generated. Why is it different from what the NAS algorithm expects? How do I solve this error?
Extra info: According to this site, it's supposed to be due to a version conflict, but even upgrading to FROM synadia/nats-account-server:1.0.0 didn't solve it.
BitBake fails for me because it can't find https://www.example.com.
My computer is an x86-64 running native Xubuntu 18.04. Network connection is via DSL. I'm using the latest versions of the OpenEmbedded/Yocto toolchain.
This is the response I get when I run BitBake:
$ bitbake -k core-image-sato
WARNING: Host distribution "ubuntu-18.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:
Fetcher failure for URL: 'https://www.example.com/'. URL https://www.example.com/ doesn't work.
Please ensure your host's network is configured correctly,
or set BB_NO_NETWORK = "1" to disable network access if
all required sources are on local disk.
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
The networking issue, the reason why I can't access www.example.com, is a question for the SuperUser forum. My question here is, why does BitBake rely on the existence of www.example.com? What is it about that website that is so vital to BitBake's operation? Why does BitBake post an Error if it cannot find https://www.example.com?
At this time, I don't wish to set BB_NO_NETWORK = "1". I would rather understand and resolve the root cause of the problem first.
Modifying poky.conf didn't work for me (and from what I read, modifying anything under Poky is a no-no for a long term solution).
Modifying /conf/local.conf was the only solution that worked for me. Simply add one of the two options:
#check connectivity using google
CONNECTIVITY_CHECK_URIS = "https://www.google.com/"
#skip connectivity checks
CONNECTIVITY_CHECK_URIS = ""
This solution was originally found here.
For me, this appears to be a problem with my ISP (CenturyLink) not correctly resolving www.example.com. If I try to navigate to https://www.example.com in the browser address bar I just get taken to the ISP's "this is not a valid address" page.
Technically speaking, this isn't supposed to happen, but for whatever reason it does. I was able to work around this temporarily by modifying the CONNECTIVITY_CHECK_URIS in poky/meta-poky/conf/distro/poky.conf to something that actually resolves:
# The CONNECTIVITY_CHECK_URI's are used to test whether we can succesfully
# fetch from the network (and warn you if not). To disable the test set
# the variable to be empty.
# Git example url: git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=master
CONNECTIVITY_CHECK_URIS ?= "https://www.google.com/"
See this commit for more insight and discussion on the addition of the www.example.com check. Not sure what the best long-term fix is, but the change above allowed me to build successfully.
If you want to resolve this issue without modifying poky.conf or local.conf or any of the files for that matter, just do:
$touch conf/sanity.conf
It is clearly written in meta/conf/sanity.conf that:
Expert users can confirm their sanity with "touch conf/sanity.conf"
If you don't want to execute this command on every session or build, you can comment out the line INHERIT += "sanity" from meta/conf/sanity.conf, so the file looks something like this:
Had same issue with Bell ISP when accessing example.com gave DNS error.
Solved by switching ISP's DNS IP to Google's DNS (to avoid making changes to configs):
https://developers.google.com/speed/public-dns/docs/using
In PostgreSQL, whenever I execute an API URL with secure connection with query
like below
select *
from http_get('https://url......');
I get an error
SSL certificate problem: unable to get local issuer certificate
For this I have already placed a SSL folder in my azure database installation file at following path
C:\Program Files\PostgreSQL\9.6\ssl\certs
What should I do to get rid of this? Is there any SSL extension available, or do I require configuration changes or any other effort?
Please let me know the possible solutions for it.
A few questions...
First, are you using this contrib module: https://github.com/pramsey/pgsql-http ?
Is the server that serves https://url....... using a self-signed (or invalid) certificate?
If the answer to those two questions is "yes" then you may not be able to use that contrib module without some modification. I'm not sure how limited your access is to PostgreSQL in Azure, but if you can install your own C-based contrib modules there is some hope...
pgsql-http only exposes certain CURLOPTs (see: https://github.com/pramsey/pgsql-http#curl-options) values which are settable with http_set_curlopt()
For endpoints using self-signed certificates, I expect the CURLOPT you'll want to include support for to ignore SSL errors is CURLOPT_SSL_VERIFYPEER
If there are other issues like SSL/TLS protocol or cipher mismatches, there are other CURLOPTs that can be patched-in, but those also are not available without customization of the contrib module.
I don't think anything in your
C:\Program Files\PostgreSQL\9.6\ssl\certs
folder has any effect on the http_get() functionality.
If you don't want to get your hands dirty compiling and installing custom contrib modules, you can create an issue on the github page of the maintainer and see if it gets picked up.
You might also take a peek at https://github.com/pramsey/pgsql-http#why-this-is-a-bad-idea because the author of the module makes several very good points to consider.