/dev/random does not block, emits poor entropy

For contrast, here is a 'rngtest' run against a 3.1.8 Linux kernel with /dev/random enhanced by the output of a STMicroelectronics ST33 TPM PRNG (via 'rngd' v4). bits received from input: 62380032 FIPS 140-2 successes: 3115 FIPS 140-2 failures: 4 FIPS 140-2(2001-10-10) Monobit: 0 FIPS 140-2(2001-1

/dev/random does not block, emits poor entropy

I see that CryptGenRandom() does not appear to have parameters to detect or control the quality of entropy. So possibly the correct solution to this issue would be to eliminate /dev/random and just leave /dev/urandom in place. 'openssl' apparently uses /dev/urandom. If someone needs

/dev/random does not block, emits poor entropy

Hello, While poking around TRNG quality I came across this apparent issue: /dev/random does not block, emits poor entropy Running 1.7.17 but see no updates in the 1.7.18 thru 1.7.25 Changelog entries regarding /dev/random. Due to 'argp' library issues I could not compile 'rngtest' under Cygw

RE: possible bug in 1.7.22-1 core DLLs

Fixes the CTRL-C problem and the point behind it all, running a critical build script, work as well. > >stephan($0.02); > >-Original Message- >From: cygwin-owner at cygwin dot com >On Behalf Of starlight.2013z3 at binnacle dot cx >Sent: Wednesday, July 31, 2013 10:26 AM >

Re: possible bug in 1.7.22-1 core DLLs

Well I uncovered a serious regression and expressed a willingness to track down the cause. However your nasty reply and bad attitude assures that I will defintiely not help now. At 01:21 PM 7/31/2013 -0400, Christopher Faylor wrote: >You are right in assuming that newer DLLs should >work with old

possible bug in 1.7.22-1 core DLLs

Hello, Have been running 1.7.16 for some time and living with the annoying CTRL-C hang bug. Tried swapping in cygwin1.dll cyglsa.dll and cyglsa64.dll from 1.7.22-1 without (thankfully) updating the entire CYGWIN release. The 22-1 DLLs fix the CTRL-C problem, but cause a high-intensity parallel b

large performance improvement 1.7.5 -> 1.7.16

Hello, Recently upgraded from 1.7.5 to 1.7.16. Just noticed that a large compile is running 35% faster with the new version--an impressive jump. Curious if anyone knows what change(s) might have done that. The compile runs over a CIFS share to Samba server 3.6.4 on CentOS 5.8. Physical transpor

Re: question: 'nxclient' won't connect with cygwin1.dll 1.7.16

Narrowed this down some. Posting for future Googlers. Looks like the culprit is probably What's new and what changed from 1.7.7 to 1.7.8 * Drop support for Windows NT4 prior to Service Pack 4. per http://cygwin.com/cygwin-ug-net/ov-new1.7.html Looking at the NXWin log output I get

Re: question: 'nxclient' won't connect with cygwin1.dll 1.7.16

Bisected it and found 1.7.7 works and 1.7.8 does not. Nothing in the 1.7.8 change overview seems likely. Also found the source is available. 'NXWin' looks like it fits in the X11 build tree and is a more-or-less typical X application. So the solution, when it becomes important is to recompile it

Re: question: 'nxclient' won't connect with cygwin1.dll 1.7.16

The logs say that NXWin.exe is failing on startup with an exit code of 259 If anyone thinks then can make sense of it, I could run 'procmon64' on NXWin and trace the Windows systems calls in it. Could run any applicable CYGWIN tools as well. -- Problem reports: http://cygwin.com/probl

question: 'nxclient' won't connect with cygwin1.dll 1.7.16

Hello, Just upgraded from 1.7.5 to 1.7.16. Curiously the NoMachine 'nxclient' application doesn't work when the latest 'cygwin1.dll' is copied into it's bin directory. However it works fine with the older 1.7.5 'cygwin1.dll'. Using the 1.7.5 DLL with 'nxclient' does not seem to cause problems w

Re: CYGWIN inode over Samba share not constructed from IndexNumber

At 07:58 PM 5/11/2012 +0200, Corinna Vinschen wrote: >Which Samba version introduced this behaviour? Don't know. I'm stepping aside on this now. Just reported it since it came up and broke a script we have. I've worked around the inode test by comparing 'sha1sum' values for the files and re-har

Re: CYGWIN inode over Samba share not constructed from IndexNumber

Here is the logic Samba uses for inode determination, per Jermey Allison: Ok, here's how we construct the 64-bit return value for that field: / Create a 64 bit FileIndex. If the file is on the same device as the root of the s

Re: CYGWIN inode over Samba share not constructed from IndexNumber

At 06:23 PM 5/11/2012 +0200, Corinna Vinschen wrote: >Additionally, the returned file ID must be > 0x, >otherwise we don't trust the server to generate >usefule file IDs. This usually only affects remote >NT4 NTFS and Samba < 3.0. Running Samba 3.6.4 and it is returning IndexNumber:

CYGWIN inode over Samba share not constructed from IndexNumber

Hello, Ran into a quirk that caused some trouble. For some reason CYGWIN 1.7.5 (I know this is old) is constructing inode values for files on Samba (3.6.4) shares with a different algorithm than is used for files on NTFS volumes. This caused a script that checks for matching hard-links to fail.

'mkgroup -lu' error and/or missing group member names

Hello, When mkgroup -lu is run on a current (as of today) install of CYGWIN 1.7.4, it returns the error mkgroup (376): [1722] The RPC server is unavailable. Running any of mkgroup -l -u mkgroup -u -l mkgroup -ul does not result in an error message, but also does not include m

setting default group and/or disabling CYGWIN ACL behavior

Constantly have to wrestle with CYGWIN imposed ACLs on files I create. It's bothersome to constantly issue 'cacls /t' and 'icacls * /reset /t' commands to strip out the CYGWIN overrides after receiving complaints from others who can't access the files. No one is in the Administrators group.