The kubernetes docs allow for multiple containers in a pod. When might this be a good idea and how are failures handled?
Arne, | |
Thanks for your candid email. I appreciate it. | |
I am encouraged by the fact that you had AES-128 encrypted data my card payment details. Yet it the fact that | |
you don't know whether the key was stolen means that we need to assume it was. | |
What I am concerned about is that you don't need to actually ever store card details if you use the latest | |
payments technology. Holding "card on file" is a legacy technique. The modern approach given GDPR liability | |
is to not hold the card details but an encrypted card token. Your card acquirer gateway can then hold the |
#!/bin/sh -e | |
if [[ ! -z ${DB_HOST_LIST} ]]; then | |
echo "Selecting DB_HOST from ${DB_HOST_LIST}" | |
SELECT_LIST_SEPERATOR="," | |
SELECT_ARRAY=( ${DB_HOST_LIST//$SELECT_LIST_SEPERATOR/ } ) | |
export DB_HOST="${SELECT_ARRAY[$RANDOM % ${#SELECT_ARRAY[@]}]}" | |
echo "DB_HOST=${DB_HOST}" | |
fi |
version: 2.0 | |
jobs: | |
build: | |
docker: | |
- image: "registry.access.redhat.com/rhscl/php-71-rhel7:latest" | |
steps: | |
- checkout: | |
path: /tmp/src/ | |
# Download and cache dependencies |
public static final String FORMAT_NAME = "jpg"; // change me to png! | |
public final static void generateImage(final String text, final String fileNameWithoutExt) throws Exception { | |
/* | |
Because font metrics is based on a graphics context, we need to create | |
a small, temporary image so we can ascertain the width and height | |
of the final image | |
*/ | |
BufferedImage img = new BufferedImage(1, 1, BufferedImage.TYPE_INT_ARGB); |
Below are my build instructions for GnuPG 2.2.9, released on July 12th, 2018. These instructions are built for a headless Centos 7 LTS server (specificaly the openshift/base-centos7 docker image).
You use the below install script to install GnuPG 2.2.x by running the following commands:
# if you are root in a docker image:
curl -OL "https://gist.githubusercontent.com/simbo1905/ba3e8af9a45435db6093aea35c6150e8/raw/83561e214e36f6556fd6b1ec0a384cf28cb2debf/install-gnupg22.sh" && bash ./install-gnupg22.sh
# else if you need to sudo to do the installs:
# If there is a repo in, say Heroku, or say BitBucket, and you want to push to it code from GitHub | |
git remote add upstream [email protected]:hyperledger/indy-sdk.git | |
# pull everything from upstream clobbering anything local (assumes you start with an empty repo) | |
git pull -s recursive -X theirs upstream master |
This is the code that goes with the presentation at https://docs.google.com/presentation/d/1kQhNGoVdoXhnsfwnsgmEBYMftVYR1Vx8QqdCqWSZXiI
These instructions are how to setup what I demoed in that presentation. It is a realistic backend API and frontend SPA. Due to time constraints my presentation demo will start with a working setup and the section "Some 'real world' things to demo in the presentation". All the steps to set everything up are below.
The demo code we will deploy is part of the www.realworld.io project where different people write alternative interoperable frontends or backends. Below I have chosen ReactJS and Laravel but you could use any of the demo apps that use different langages and frameworksgs
#!/bin/bash | |
if [ "$NAME" = "" ] | |
then | |
echo "You must set NAME of the secet as an env var" | |
exit 1 | |
else | |
echo "Creating secet/$NAME" | |
fi |
NIST recommends that when users are trying to set a password you should reject those that are commonly used or compromised:
When processing requests to establish and change memorized secrets,
verifiers SHALL compare the prospective secrets against a list that
contains values known to be commonly-used, expected, or compromised.
But how do you know what are the compromised passwords? Luckily Troy Hunter put a lot of effort into building the "Have I Been Pwned (HIBP)" database with the SHA1 hashes of 501,636,842 passwords that have been compromised on the internet. Sweet.