{"action":"created","issue":{"url":"https://api.github.com/repos/SWI-Prolog/packages-ssl/issues/76","repository_url":"https://api.github.com/repos/SWI-Prolog/packages-ssl","labels_url":"https://api.github.com/repos/SWI-Prolog/packages-ssl/issues/76/labels{/name}","comments_url":"https://api.github.com/repos/SWI-Prolog/packages-ssl/issues/76/comments","events_url":"https://api.github.com/repos/SWI-Prolog/packages-ssl/issues/76/events","html_url":"https://github.com/SWI-Prolog/packages-ssl/issues/76","id":194830679,"number":76,"title":"Suggestion: library(crypto)","user":{"login":"triska","id":7482140,"avatar_url":"https://avatars.githubusercontent.com/u/7482140?v=3","gravatar_id":"","url":"https://api.github.com/users/triska","html_url":"https://github.com/triska","followers_url":"https://api.github.com/users/triska/followers","following_url":"https://api.github.com/users/triska/following{/other_user}","gists_url":"https://api.github.com/users/triska/gists{/gist_id}","starred_url":"https://api.github.com/users/triska/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/triska/subscriptions","organizations_url":"https://api.github.com/users/triska/orgs","repos_url":"https://api.github.com/users/triska/repos","events_url":"https://api.github.com/users/triska/events{/privacy}","received_events_url":"https://api.github.com/users/triska/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":7,"created_at":"2016-12-11T13:00:59Z","updated_at":"2016-12-12T18:35:47Z","closed_at":null,"body":"Currently, `library(ssl)` supplies both\r\n\r\n  1.  **connection-oriented** predicates that are very heavily used in web servers and clients\r\n  2. **cryptographic** and **authenticity**-related predicates that can be sensibly used in isolation, and cater mostly to more specialized use cases.\r\n\r\nIn the first group, the most notable are:\r\n\r\n  - `ssl_context/3`\r\n  - `ssl_negotiate/5`\r\n  - `ssl_session/2`\r\n\r\nas well as some predicates retained for backwards compatibility with the deprecated interface (`ssl_init/3` etc.).\r\n\r\nIn the second group, we have:\r\n\r\n  - `evp_decrypt/6`\r\n  - `evp_encrypt/6`\r\n  - `load_certificate/2`\r\n  - `load_private_key/3`\r\n  - `load_public_key/2`\r\n  - `load_crl/2`\r\n  - `rsa_private_decrypt/3`\r\n  - `rsa_private_encrypt/3`\r\n  - `rsa_public_decrypt/3`\r\n  - `rsa_public_encrypt/3`\r\n  - `rsa_private_decrypt/4`\r\n  - `rsa_private_encrypt/4`\r\n  - `rsa_public_decrypt/4`\r\n  - `rsa_public_encrypt/4`\r\n  - `rsa_sign/4`\r\n  - `rsa_verify/4`\r\n\r\nThese predicates *may* be used in the context of a connection, and also make sense in isolation. It makes sense that loading `library(ssl)` *also* provides these predicates. However, there are several more predicates that could be provided by adding suitable bindings to the `libcrypto` functions of&nbsp;OpenSSL. For example:\r\n\r\n  - `md5_hash/2`\r\n  - `sha1_hash/2`\r\n\r\netc., with the prospect of many more in the future for special purposes.\r\n\r\nAdding all these predicates to the \"core\" `library(ssl)` documentation makes it rather unwieldy.\r\n\r\nI suggest to move predicates of the second category to the new `library(crypto)`, as a new part of the `ssl` package, and include a pointer from `library(ssl)` to these predicates. What do you think?"},"comment":{"url":"https://api.github.com/repos/SWI-Prolog/packages-ssl/issues/comments/266512749","html_url":"https://github.com/SWI-Prolog/packages-ssl/issues/76#issuecomment-266512749","issue_url":"https://api.github.com/repos/SWI-Prolog/packages-ssl/issues/76","id":266512749,"user":{"login":"triska","id":7482140,"avatar_url":"https://avatars.githubusercontent.com/u/7482140?v=3","gravatar_id":"","url":"https://api.github.com/users/triska","html_url":"https://github.com/triska","followers_url":"https://api.github.com/users/triska/followers","following_url":"https://api.github.com/users/triska/following{/other_user}","gists_url":"https://api.github.com/users/triska/gists{/gist_id}","starred_url":"https://api.github.com/users/triska/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/triska/subscriptions","organizations_url":"https://api.github.com/users/triska/orgs","repos_url":"https://api.github.com/users/triska/repos","events_url":"https://api.github.com/users/triska/events{/privacy}","received_events_url":"https://api.github.com/users/triska/received_events","type":"User","site_admin":false},"created_at":"2016-12-12T18:35:47Z","updated_at":"2016-12-12T18:35:47Z","body":"I cannot regard \"I'll go along\" as a satisfying conclusion of this issue. I want users to have a benefit from this separation, and would like to find a solution that you fully support and endorse!\r\n\r\nHow about #78 ? This completely **disentagles**`library(crypto)` from `libssl`, so that we now have the structure:\r\n\r\n - library(ssl)\r\n   - ssl4pl.so\r\n      - ssllib.so\r\n - library(crypto)\r\n   - crypto4pl.so\r\n      - cryptolib.so\r\n\r\nThus, you can use the cryptographic predicates without loading the full SSL library.\r\n\r\nThe introduction of [`library(md5)`](http://eu.swi-prolog.org/pldoc/man?section=md5) states:\r\n\r\n> This is a rather short-term solution waiting for a more general interface to the `libcrypto` functions of OpenSSL.\r\n\r\nI wonder what is or was meant by this, if not exactly this functionality that is now available?\r\n"}}
{"actor":{"display_login":"triska"}}