1 files changed, 0 insertions, 77 deletions
diff --git a/raw-wiki-dump/GitRepositories%2Fsw%2Fpkcs11 b/raw-wiki-dump/GitRepositories%2Fsw%2Fpkcs11
deleted file mode 100644
index 5a68bed..0000000
--- a/raw-wiki-dump/GitRepositories%2Fsw%2Fpkcs11
+++ /dev/null
@@ -1,77 +0,0 @@
-{{{
-#!htmlcomment
-
-This page is maintained automatically by a script.  Don't modify this page by hand,
-your changes will just be overwritten the next time the script runs.  Talk to your
-Friendly Neighborhood Repository Maintainer if you need to change something here.
-
-}}}
-
-{{{
-#!html
-<h1>PKCS #11</h1>
-
-<h2>Introduction</h2>
-
-<p>This is an implementation of the <a href="http://www.cryptsoft.com/pkcs11doc/STANDARD/" title="PKCS #11">PKCS11</a> API for the <a href="https://cryptech.is/" title="Cryptech">Cryptech</a>
-project.  Like most PKCS #11 implementations, this one is incomplete
-and probably always will be: PKCS #11 is very open-ended, and the
-specification includes enough rope for an unwary developer to hang not
-only himself, but all of his friends, relations, and casual
-acquaintances.</p>
-
-<p>Along with the PKCS #11 library itself, the package includes a
-companion Python interface ("cryptech.py11"), which uses the ctypes
-module from the Python standard library to talk to the PKCS #11
-implementation.  The Python implementation is intended primarily to
-simplify testing the C code, but can be used for other purposes; while
-it seems unlikely that anything could ever make PKCS #11 "fun", the
-<code>cryptech.py11</code> library attempts to make it a bit less awful by
-providing both direct acess to the raw PKCS #11 API and a somewhat
-more "pythonic" API layered on top of the raw API.</p>
-
-<h2>Novel design features</h2>
-
-<p><a href="http://www.cryptsoft.com/pkcs11doc/STANDARD/" title="PKCS #11">PKCS11</a>'s data model involves an n-level-deep hierarchy of object
-classes, which is somewhat tedious to implement correctly in C,
-particularly if one wants the correspondence between specification and
-code to be at all obvious.  In order to automate much of the drudge
-work involved, this implementation uses an external representation of
-the object class hierarchy, which is processed at compile time by a
-Python script to generate tables which drive the C code which performs
-the necessary type checking.</p>
-
-<h2>Current status</h2>
-
-<p>As of this writing, the implementation supports only the RSA, ECDSA,
-SHA-1, and SHA-2 algorithms, but the design is intended to be
-extensible.</p>
-
-<p>The underlying cryptographic support comes from the <a href="https://cryptech.is/" title="Cryptech">Cryptech</a>
-<code>libhal</code> package.</p>
-
-<p>Testing to date has been done using the <code>bin/pkcs11/</code> tools from the
-BIND9 distribution, the <code>hsmcheck</code> and <code>ods-hsmutil</code> tools from the
-OpenDNSSEC distribution, the <code>hsmbully</code> diagnostic tool, the Google
-<code>pkcs11test</code> test suite, and a somewhat ad hoc set of unit tests using
-Python's unittest library along with our own <code>cryptech.py11</code> library.</p>
-
-<p>The library is also known to work as an <code>OpenSSL</code> engine when used
-with the <code>engine-pkcs11</code> package spun out of the OpenSC project.  This
-has not been tested extensively, but key generation, signature, and
-verification all work (with RSA keys -- the engine appears not to
-understand ECDSA keys, we have not investigated into details here).</p>
-
-<h2>Copyright status</h2>
-
-<p>The <a href="http://www.cryptsoft.com/pkcs11doc/STANDARD/" title="PKCS #11">PKCS11</a> header files are "derived from the RSA Security Inc.
-PKCS #11 Cryptographic Token Interface (Cryptoki)".  See the
-<code>pkcs11*.h</code> header files for details.</p>
-
-<p>Code written for the <a href="https://cryptech.is/" title="Cryptech">Cryptech</a> project is under the usual Cryptech
-BSD-style license.</p>
-}}}
-
-[[RepositoryIndex(format=table,glob=sw/pkcs11)]]
-
-|| Clone `https://git.cryptech.is/sw/pkcs11.git` ||