| #!/bin/bash | |
| # | |
| # (Above line comes out when placing in Xcode scheme) | |
| # | |
| API_TOKEN=<TestFlight API token here> | |
| TEAM_TOKEN=<TestFlight team token here> | |
| SIGNING_IDENTITY="iPhone Distribution: Development Seed" | |
| PROVISIONING_PROFILE="${HOME}/Library/MobileDevice/Provisioning Profiles/MapBox Ad Hoc.mobileprovision" | |
| #LOG="/tmp/testflight.log" |
| #!/bin/sh | |
| ### | |
| # SOME COMMANDS WILL NOT WORK ON macOS (Sierra or newer) | |
| # For Sierra or newer, see https://github.com/mathiasbynens/dotfiles/blob/master/.macos | |
| ### | |
| # Alot of these configs have been taken from the various places | |
| # on the web, most from here | |
| # https://github.com/mathiasbynens/dotfiles/blob/5b3c8418ed42d93af2e647dc9d122f25cc034871/.osx |
| --- | |
| language: objective-c | |
| before_script: | |
| - ./scripts/travis/add-key.sh | |
| after_script: | |
| - ./scripts/travis/remove-key.sh | |
| after_success: | |
| - ./scripts/travis/testflight.sh | |
| env: | |
| global: |
| language: objective-c | |
| xcode_workspace: "<WorkspaceName.xcworkspace>" | |
| xcode_scheme: "<SchemaName>" | |
| script: xctool -workspace <WorkspaceName.xcworkspace> -scheme <SchemeName> -configuration Release build archive | |
| before_script: | |
| - ./scripts/travis/add-key.sh | |
| after_script: | |
| - ./scripts/travis/remove-key.sh | |
| after_success: | |
| - ./scripts/travis/testflight.sh |
| language: objective-c | |
| before_script: | |
| - chmod +x scripts/travis/add-key.sh | |
| - chmod +x scripts/travis/remove-key.sh | |
| - chmod +x scripts/travis/testflight.sh | |
| - ./scripts/travis/add-key.sh | |
| script: xctool -workspace [Workspace name].xcworkspace -scheme '[Scheme to use]' -configuration [Build configuration name] -sdk iphoneos7.1 CONFIGURATION_BUILD_DIR='~/build/' build | |
| after_success: | |
| - ./scripts/travis/testflight.sh | |
| after_script: |
| #!/bin/bash | |
| # Bash script for setting or clearing touch requirements for | |
| # cryptographic operations the OpenPGP application on a YubiKey 4. | |
| # | |
| # Author: Alessio Di Mauro <alessio@yubico.com> | |
| GCA=$(which gpg-connect-agent) | |
| DO=0 | |
| UIF=0 |
On Twitter the other day, I was lamenting the state of OCSP stapling support on Linux servers, and got asked by several people to write-up what I think the requirements are for OCSP stapling support.
Support for keeping a long-lived (disk) cache of OCSP responses.
This should be fairly simple. Any restarting of the service shouldn't blow away previous responses that were obtained. This doesn't need to be disk, just stable - and disk is an easy stable storage for most server
| # tasks/main.yml | |
| - name: install certbot dependencies | |
| apt: name={{ item }} state=present | |
| with_items: | |
| - build-essential | |
| - libssl-dev | |
| - libffi-dev | |
| - python-dev | |
| - git |
Similar to my advice regarding OCSP Stapling for servers/server developers, based on questions I've received about "CT best practices," I wanted to write something similar for those writing server software. That is, this isn't targeted at server operators, but for those writing software like Apache, nginx, Caddy, etc.
At the most basic level, the deployment of Certificate Transparency to date has largely tried to focus the burden on CAs, rather than on server developers. If the CA is doing everything right,
| #!/bin/zsh | |
| :<<'ABOUT_THIS_SCRIPT' | |
| ----------------------------------------------------------------------- | |
| Written by:William Smith | |
| Partner Program Manager | |
| Jamf | |
| bill@talkingmoose.net | |
| https://gist.github.com/b6637160b65b751824943ede022daa17 |
