For excessively paranoid client authentication.
Organization & Common Name: Some human identifier for this server CA.
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
<?php | |
$baseUrl = "http://localhost/packagist"; | |
$baseDir = "/var/www/packagist"; | |
if (!file_exists($baseDir)) { | |
echo "Base dir $baseDir for local packagist proxy does not exist\n"; | |
exit(1); | |
} | |
$packagesJson = $baseDir . "/packages.json"; |
For excessively paranoid client authentication.
Organization & Common Name: Some human identifier for this server CA.
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
#!/bin/sh | |
KERNEL="/path/to/vmlinuz64" | |
INITRD="/path/to/initrd.img" | |
#CMDLINE="earlyprintk=serial console=ttyS0 acpi=off" | |
CMDLINE="loglevel=3 user=docker console=ttyS0 console=tty0 noembed nomodeset norestore waitusb=10:LABEL=boot2docker-data base" | |
MEM="-m 1G" | |
#SMP="-c 2" | |
NET="-s 2:0,virtio-net,en0" |
Semi-private keys are an expansion of the traditional idea of asymmetric keys, which have a public/private keypair, to N keys which can each represent a different capability level. In the degenerate case, a semi-private key system has 3 different types of keys. These are, to use the Tahoe terminology:
It might seem like a silly exercise, but I was looking at the "NIST approved" algorithms in NaCl (i.e. AES, HMAC) and wondering if I could build an authenticated encryption system with them. djb lists AES-GCM as a "todo" secretbox primitive so unfortunately NaCl does not presently expose any AES-based authenticated encryption, only aes128ctr.
This is what I came up with using the algorithms available in NaCl:
A quick rundown:
Encrypt-then-MAC with AES-CTR (128-bit for now, 256-bit later!) encryption and HMAC SHA-512256 (i.e. SHA-512, truncated to 256-bits by NaCl via crypto_auth_hmacsha512256) authentication. MAC comparisons are performed using a NaCl supplied verifier function which is (hopefully!) constant time.
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> | |
<name>Win10-IGD</name> | |
<uuid>YOUR-UUID</uuid> | |
<memory unit='KiB'>5939200</memory> | |
<currentMemory unit='KiB'>5939200</currentMemory> | |
<memoryBacking> | |
<hugepages/> | |
</memoryBacking> | |
<vcpu placement='static'>4</vcpu> | |
<os> |
Install OS X El Capitan
is created#!/usr/bin/env python | |
#-*- coding: utf-8 -*- | |
''' | |
Copyleft (c) 2015 breakwa11 | |
https://github.com/breakwa11/shadowsocks-rss | |
''' | |
import logging | |
import socket |
Hello, brethren :-)
As it turns out, the current version of FFmpeg (version 3.1 released earlier today) and libav (master branch) supports full H.264 and HEVC encode in VAAPI on supported hardware that works reliably well to be termed "production-ready".
Hello guys,
Continuing from this guide to building ffmpeg and libav with NVENC and VAAPI enabled, this snippet will cover advanced options that you can use with ffmpeg and libav on both NVENC and VAAPI hardware-based encoders.
For ffmpeg: