# syslog : "Libgcrypt warning: missing initialization"

## toralf

Few times I got in my syslog :

```
n22 ~ # zgrep gcrypt /var/log/messages*                                                                                                                               

/var/log/messages:2012-07-20T18:45:05.000+02:00 n22 srtp-test-aes: Libgcrypt warning: missing initialization - please fix the application                             

/var/log/messages:2012-07-20T18:45:05.000+02:00 n22 srtp-test-recv: Libgcrypt warning: missing initialization - please fix the application                            

/var/log/messages-20120701.gz:2012-06-25T20:05:44.000+02:00 n22 t-ssh-utils: Libgcrypt warning: missing initialization - please fix the application                   

/var/log/messages-20120701.gz:2012-06-25T20:37:57.000+02:00 n22 t-ssh-utils: Libgcrypt warning: missing initialization - please fix the application                   

/var/log/messages-20120708.gz:2012-07-01T18:56:19.000+02:00 n22 srtp-test-aes: Libgcrypt warning: missing initialization - please fix the application                 

/var/log/messages-20120708.gz:2012-07-01T18:56:19.000+02:00 n22 srtp-test-recv: Libgcrypt warning: missing initialization - please fix the application                
```

Anything I should do care for ?Last edited by toralf on Sat Jul 21, 2012 11:59 am; edited 2 times in total

----------

## khayyam

toralf ...

the issue is how these applications (srtp-test-aes, srtp-test-recv, etc) are allowed to access/use memory (see section 2.4 Initializing the library in the libgrypt documentation for more information). Basically, libgrypt expects that memory allocated will be "secure memory" (not swapped out to disk, etc), but such things are dependent on the 'capabilities' of the user running the application (they must be allowed to lock the memory used). So, its something the system needs to allow (ie: via CAP_IPC_LOCK capability) which is configured via /etc/security/limits.conf, memlock (RLIMIT_MEMLOCK) if I remember correctly.

Of course, the applications may not be coded to check such things, so I can say for certain that this will fix things, you should check any documentaion provided for advice on how to avoid using insecure memory.

HTH & best ...

khay

----------

## toralf

Upstream (https://trac.videolan.org/vlc/ticket/7179#comment:1) wrote : *Quote:*   

> 
> 
> It's not fixable on VLC side. gcrypt is hidden inside multiple levels of libraries and modules. VLC does not "see" gcrypt directly, so it cannot initialize it.
> 
> Any library that expects static one time initialization is seriously broken by design. Please fix gcrypt if this is a problem for you. Thanks.
> ...

 Hhm, /me wonders whether this is a problem just for the test cases on my system or whether the packager/s should be informed/bothered.

----------

## khayyam

 *Quote:*   

> Any library that expects static one time initialization is seriously broken by design.

 

toralf ... I would generally agree with that assessment, but its no different to libproxy, libnotify, or perhaps a hundred other libraries ... and what would happen if say vlc had a memory leak, the system/kernel should dynamically recognise this and set a limit? I'm not arguing that libgcrypt is doing it right but I also don't think vlc can simply claim its the libraries problem.

best ... khay

----------

