| # <type>: (If applied, this commit will...) <subject> (Max 50 char) | |
| # |<---- Using a Maximum Of 50 Characters ---->| | |
| # Explain why this change is being made | |
| # |<---- Try To Limit Each Line to a Maximum Of 72 Characters ---->| | |
| # Provide links or keys to any relevant tickets, articles or other resources | |
| # Example: Github issue #23 |
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
I've been looking for the best Linux backup system, and also reading lots of HN comments.
Instead of putting pros and cons of every backup system I'll just list some deal-breakers which would disqualify them.
Also I would like that you, the HN community, would add more deal breakers for these or other backup systems if you know some more and at the same time, if you have data to disprove some of the deal-breakers listed here (benchmarks, info about something being true for older releases but is fixed on newer releases), please share it so that I can edit this list accordingly.
This is way more complicated than it should be. The following conditions need to be met :
In this particular case, I'm interested in bringing in the 'default' template of jsdoc as a sub-directory in my project so I could potentially make changes to the markup it genereates while also being able to update from upstream if there are changes. Ideally their template should be a separate repo added to jsdoc via a submodule -- this way I could fork it and things would be much easier.... but, it is what it is.
After much struggling with git, subtree and git-subtree, I ended up finding this http://archive.h2ik.co/2011/03/having-fun-with-git-subtree/ -- it basically sets up separate branches from tracking remote, the particular sub-directory, and uses git subtree contrib module to pull it all togther. Following are
This is a guide on how to email securely.
There are many guides on how to install and use PGP to encrypt email. This is not one of them. This is a guide on secure communication using email with PGP encryption. If you are not familiar with PGP, please read another guide first. If you are comfortable using PGP to encrypt and decrypt emails, this guide will raise your security to the next level.
This configuration is not maintained anymore. You should think twice before using it, Breaking change and security issue will likely eventually happens as any abandonned project.
THIS GIST WAS MOVED TO TERMSTANDARD/COLORS REPOSITORY.
PLEASE ASK YOUR QUESTIONS OR ADD ANY SUGGESTIONS AS A REPOSITORY ISSUES OR PULL REQUESTS INSTEAD!
| Date: 17 Aug 2013 00:24:45 -0000 | |
| From: "D. J. Bernstein" <[email protected]> | |
| To: [email protected] | |
| Subject: Re: [cryptography] urandom vs random | |
| Aaron Toponce writes: | |
| > Cryptographers don't like the idea that it's possible, even if it's | |
| > excessively remote, and highly unprobable. This is why you see suggestions | |
| > to use /dev/random for long term SSH, SSL and OpenPGP keys. |
