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.
#!/usr/bin/env python | |
#-*- coding: utf-8 -*- | |
''' | |
Copyleft (c) 2015 breakwa11 | |
https://github.com/breakwa11/shadowsocks-rss | |
''' | |
import logging | |
import socket |
<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 createdEnable overrides for missing ACS capabilities (4.10+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index be7c0d9506b1..97081bbc9a4e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2829,6 +2829,15 @@
nomsi [MSI] If the PCI_MSI kernel config parameter is
enabled, this kernel boot option can be used to
disable the use of MSI interrupts system-wide.
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".