A caller may want to specify an explicit order of PAC elements,
e.g. the PAC_UPN_DNS_INFO element should be placed after the PAC_LOGON_NAME
element.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
This is just a hack to get Appveyor builds to complete successfully.
Eventually we should get packages and installers to build correctly, and
even for x86 and x86_64 combined. But it's early days and this is
useful enough.
The build was failing at lib/hcrypto/evp-pkcs11.c because roken.h was
being included after <assert.h>. It's not clear why that would be a
problem.
Here are some of the errors and warnings that resulted from including
<roken.h> after <assert.h> in evp-pkcs11.c:
evp-pkcs11.c C:\Program Files\Microsoft SDKs\Windows\v7.1\INCLUDE\ws2def.h(91) : warning C4005: 'AF_IPX' : macro redefinition s C:\Program Files\Microsoft SDKs\Windows\v7.1\INCLUDE\winsock.h(460) : see previous definition of 'AF_IPX'
C:\Program Files\Microsoft SDKs\Windows\v7.1\INCLUDE\ws2def.h(124) : warning C4005: 'AF_MAX' : macro redefinition
C:\Program Files\Microsoft SDKs\Windows\v7.1\INCLUDE\winsock.h(479) : see previous definition of 'AF_MAX'
C:\Program Files\Microsoft SDKs\Windows\v7.1\INCLUDE\ws2def.h(168) : warning C4005: 'SO_DONTLINGER' : macro redefinition
C:\Program Files\Microsoft SDKs\Windows\v7.1\INCLUDE\winsock.h(402) : see previous definition of 'SO_DONTLINGER'
C:\Program Files\Microsoft SDKs\Windows\v7.1\INCLUDE\ws2def.h(212) : error C2011: 'sockaddr' : 'struct' type redefinition
C:\Program Files\Microsoft SDKs\Windows\v7.1\INCLUDE\winsock.h(485) : see declaration of 'sockaddr'
C:\Program Files\Microsoft SDKs\Windows\v7.1\INCLUDE\ws2def.h(390) : error C2059: syntax error : 'constant'
C:\Program Files\Microsoft SDKs\Windows\v7.1\INCLUDE\ws2def.h(524) : warning C4005: 'IN_CLASSA' : macro redefinition
C:\Program Files\Microsoft SDKs\Windows\v7.1\INCLUDE\winsock.h(287) : see previous definition of 'IN_CLASSA'
restore correct OID for GSS_C_PEER_HAS_UPDATED_SPNEGO, this should have no
ABI implications, it's for internal use only. The current OID was incorrectly
copied in commit dbeeb18a, it should belong to 1.3.6.1.4.1.5322.19 which is
... enterprise(1) padl(5322) gssKrb5Extensions(19). The OID we were camping
on belongs to another party.
As implemented by Jeffrey Altman heim_base_once_f() is a variant of the
"double-checked gate lock pattern". Full memory barriers must be used
when determining whether or not to call SwitchToThread().
Change-Id: I2f8446a56c50a37c921d6e993433c9a3f7488f50
Provide a Windows implementation of heim_base_once that relies upon
InterlockedCompareExchange() and SwitchToThread().
Change-Id: I9cdbda796d1a27fe1e17be63f287b10132858d7f
When __APPLE__ is defined and HCRYPTO_DEF_PROVIDER is not defined,
define HCRYPTO_DEF_PROVIDER to be "cc" so that Apple's CommonCrypto
implementations are used instead of the built-in "hcrypto"
implementations.
Change-Id: I393e5fc3f6c3b9339c96db58d926ff8ea1867cbb
We now fork(2) a number of separate KDC processes rather than a single
process. By default, the number is selected by asking how many CPUs
the machine has. We also have a master process which monitors all
of the children (which do the actual work) and it will restart kids
who die for any reason. The children will die when the parent dies.
In the case of MacOS X, we also move the bonjour code into another
separate child as it creates threads and this is known to play
rather poorly with fork(2). We could move this logic into a
designated child at some point in the future.
We slow down the spawning to one every 25ms to prevent instant crashes
and restarts from consuming all available system time. This approach
may want to be revisited in the future.
The EGD daemon is completely unmaintained and has not seen a release
since 13 years which is not an acceptable timeframe for cryptographic
software. It is not packaged in any linux distribution I know of
and definitely not in *BSD.
LibreSSL has already dropped support for RAND_egd.
A careful code review was undertaken, and it was determined
that the best way to store the extended attributes was in a
native ASN1 encoded field. LDAP does not understand the
SEQUENCE of SEQUENCE structures used extensively throughout
the extended attributes structure, and there was already a
precedent set for storing the krb5Key data in a native ASN1
encoded field.
Change 29f6290fe6 removed the
PA_ClientCanon* ASN.1 functionality but failed to remove the generated
symbols from the Windows export list.
Change-Id: I9a46532ed7d8612fbc597dec9848505d4b440e09
