A new way of writing secure code

[Ralf Senderek]

Dear developers, 

for all who wish to add reliable encryption and authentication
services to their projects with ease, I'd like to draw your
attention to cryptlib, which is available in F23, F24, rawhide
and EPEL 7 stable repositories now. Cryptlib is not just another
function collection, but offers a High-level interface that makes
it very easy for inexperienced crypto programmers to write 
secure code.

The excellent cryptlib manual is full of code examples for a 
number of languages, including C, Java, Python and Perl. 

Please have a look.
(http://www.cypherpunks.to/~peter/manual.pdf) 

Ralf.

[Florian Weimer]

On 07/04/2016 07:40 AM, Ralf Senderek wrote:
>  Dear developers,
>
>  for all who wish to add reliable encryption and authentication
>  services to their projects with ease, I'd like to draw your
>  attention to cryptlib, which is available in F23, F24, rawhide
>  and EPEL 7 stable repositories now. Cryptlib is not just another
>  function collection, but offers a High-level interface that makes
>  it very easy for inexperienced crypto programmers to write
>  secure code. 
cryptlib uses bits from OpenSSL without mangling those symbols, so there 
are symbol collisions with unpredictable effects:

   https://bugzilla.redhat.com/show_bug.cgi?id=1352404

Do you have suggestions how to comply with the anti-SaaS part of the 
cryptlib license in an automated fashion?

Thanks,
Florian

[Ralf Senderek]

>  On 07/04/2016 07:40 AM, Ralf Senderek wrote: 
>  Do you have suggestions how to comply with the anti-SaaS part of the
>
>  cryptlib license in an automated fashion? 
There is no "anti-SaaS part of the cryptlib license" The additional
clarification states that
there cannot be any exception to the requirement to provide source code to the user.

[Nikos Mavrogiannopoulos]

On Mon, 2016-07-04 at 05:40 +0000, Ralf Senderek wrote:
>  Dear developers, 
>  
>  for all who wish to add reliable encryption and authentication
>  services to their projects with ease, I'd like to draw your
>  attention to cryptlib, which is available in F23, F24, rawhide
>  and EPEL 7 stable repositories now. Cryptlib is not just another
>  function collection, but offers a High-level interface that makes
>  it very easy for inexperienced crypto programmers to write 
>  secure code. 
But it would be code that will not comply with Fedora's crypto policies
[0]. Until that happens, software using it will have inconsistent
crypto settings and thus I would not recommend using that lib in
Fedora.

regards,
Nikos

[0]. https://fedoraproject.org/wiki/Packaging:CryptoPolicies

[Ralf Senderek]

>  On Mon, 2016-07-04 at 05:40 +0000, Ralf Senderek wrote:
>  
>  But it would be code that will not comply with Fedora's crypto policies
>  [0].  
The crypto policies state:

"Since Fedora 21 (http://fedoraproject.org/wiki/Changes/CryptoPolicy) there are
policies for the usage of SSL and TLS cryptographic protocols that are enforced
system-wide. Each application being added in Fedora must be checked to comply with the
policies. Currently the policies are restricted to applications using GnuTLS and
OpenSSL,"

Why do you think any code that uses cryptlib does not comply with this?

>  Until that happens, software using it will have inconsistent
>  crypto settings and thus I would not recommend using that lib in
>  Fedora.  
One of the main benefits of using cryptlib is the fact that consistent crypto settings ARE
USED,
because the High-level interface makes it almost impossible that an inexperienced crypto 
programmer will be able to screw up the system inadvertently by choosing the wrong
parameters.