#
1.17 |
|
28-Mar-2024 |
jsing |
Remove .init section that calls OPENSSL_cpuid_setup on amd64.
OPENSSL_cpuid_setup() is already called from OPENSSL_crypto_init(), hence we do not need or want automatic initialisation on library load.
ok tb@
|
Revision tags: OPENBSD_7_5_BASE
|
#
1.16 |
|
24-Feb-2024 |
tb |
Replace uses of endbr64 with _CET_ENDBR from cet.h
cet.h is needed for other platforms to emit the relevant .gnu.properties sections that are necessary for them to enable IBT. It also avoids issues with older toolchains on macOS that explode on encountering endbr64.
based on a diff by kettenis ok beck kettenis
|
Revision tags: OPENBSD_7_4_BASE
|
#
1.15 |
|
25-Apr-2023 |
deraadt |
Add endbr64 where needed by inspection. Passes regresson tests. ok jsing, and kind of tb an earlier version
|
#
1.14 |
|
04-Apr-2023 |
anton |
A refactoring back in 2016 in which magic numbers where extracted into named constants accidentally dropped an instruction causing detection of eXtended operations (XOP) on AMD hardware to break.
ok miod@ tb@
|
Revision tags: OPENBSD_7_3_BASE
|
#
1.13 |
|
17-Jan-2023 |
miod |
Remove non-visible and unused OPENSSL_wipe_cpu and OPENSSL_atomic_add interfaces, and remove empty assembly OPENSSL_cpuid_setup routines - the default empty C fallback will work as good.
ok jsing@
|
Revision tags: OPENBSD_6_1_BASE OPENBSD_6_2_BASE OPENBSD_6_3_BASE OPENBSD_6_4_BASE OPENBSD_6_5_BASE OPENBSD_6_6_BASE OPENBSD_6_7_BASE OPENBSD_6_8_BASE OPENBSD_6_9_BASE OPENBSD_7_0_BASE OPENBSD_7_1_BASE OPENBSD_7_2_BASE
|
#
1.12 |
|
04-Nov-2016 |
miod |
Replace all uses of magic numbers when operating on OPENSSL_ia32_P[] by meaningful constants in a private header file, so that reviewers can actually get a chance to figure out what the code is attempting to do without knowing all cpuid bits.
While there, turn it from an array of two 32-bit ints into a properly aligned 64-bit int.
Use of OPENSSL_ia32_P is now restricted to the assembler parts. C code will now always use OPENSSL_cpu_caps() and check for the proper bits in the whole 64-bit word it returns.
i386 tests and ok jsing@
|
#
1.11 |
|
02-Jun-2014 |
deraadt |
A few months back there was a big community fuss regarding direct-use of the intel RDRAND instruction. Consensus was RDRAND should probably only be used as an additional source of entropy in a mixer.
Guess which library bends over backwards to provide easy access to RDRAND? Yep. Guess which applications are using this support? Not even one... but still, this is being placed as a trap for someone.
Send this support straight to the abyss. ok kettenis
|
#
1.10 |
|
24-Apr-2014 |
tedu |
repair missing semicolon. from Ian Mcwilliam
|
#
1.9 |
|
23-Apr-2014 |
miod |
Don't bother generating win64 assembly prologue.
|
#
1.8 |
|
17-Apr-2014 |
miod |
Remove oh-so-important-from-a-security-pov OpenSSL_rtdsc() function.
|
#
1.7 |
|
17-Apr-2014 |
miod |
Ok, there was a need for OPENSSL_cleanse() instead of bzero() to prevent supposedly smart compilers from optimizing memory cleanups away. Understood.
Ok, in case of an hypothetically super smart compiler, OPENSSL_cleanse() had to be convoluted enough for the compiler not to recognize that this was actually bzero() in disguise. Understood.
But then why there had been optimized assembler versions of OPENSSL_cleanse() is beyond me. Did someone not trust the C obfuscation?
|
#
1.6 |
|
13-Apr-2014 |
miod |
Merge conflicts; remove MacOS, Netware, OS/2, VMS and Windows build machinery.
|
#
1.5 |
|
31-Oct-2012 |
kettenis |
On amd64 OPENSSL_cpuid_setup and OPENSSL_ia32cap_P are now hidden so we don't have to go through the PLT/GOT to get at them anymore. In fact going through the GOT now fails since we no longer have a GOT entry for OPENSSL_ia32cap_P.
Fixes the problem spotted by jasper@ and sthen@. Based on a diff from mikeb@ who did most of the actual work of tracking down the issue.
ok millert@, mikeb@
|
#
1.4 |
|
13-Oct-2012 |
djm |
resolve conflicts
|
#
1.3 |
|
01-Oct-2010 |
djm |
resolve conflicts, fix local changes
|
#
1.2 |
|
19-Sep-2008 |
otto |
fix some cause of bad TEXTREL on i386 and amd64 - global function calls in .init sections (diff makes them via PLT) - calls to global functions in aes-586.S (made static or local) - global variable accesses in rc4-x86_64.S (now made via GOT) from djm@large; ok miod@
|
#
1.1 |
|
06-Sep-2008 |
djm |
branches: 1.1.1; Initial revision
|
#
1.16 |
|
24-Feb-2024 |
tb |
Replace uses of endbr64 with _CET_ENDBR from cet.h
cet.h is needed for other platforms to emit the relevant .gnu.properties sections that are necessary for them to enable IBT. It also avoids issues with older toolchains on macOS that explode on encountering endbr64.
based on a diff by kettenis ok beck kettenis
|
Revision tags: OPENBSD_7_4_BASE
|
#
1.15 |
|
25-Apr-2023 |
deraadt |
Add endbr64 where needed by inspection. Passes regresson tests. ok jsing, and kind of tb an earlier version
|
#
1.14 |
|
04-Apr-2023 |
anton |
A refactoring back in 2016 in which magic numbers where extracted into named constants accidentally dropped an instruction causing detection of eXtended operations (XOP) on AMD hardware to break.
ok miod@ tb@
|
Revision tags: OPENBSD_7_3_BASE
|
#
1.13 |
|
17-Jan-2023 |
miod |
Remove non-visible and unused OPENSSL_wipe_cpu and OPENSSL_atomic_add interfaces, and remove empty assembly OPENSSL_cpuid_setup routines - the default empty C fallback will work as good.
ok jsing@
|
Revision tags: OPENBSD_6_1_BASE OPENBSD_6_2_BASE OPENBSD_6_3_BASE OPENBSD_6_4_BASE OPENBSD_6_5_BASE OPENBSD_6_6_BASE OPENBSD_6_7_BASE OPENBSD_6_8_BASE OPENBSD_6_9_BASE OPENBSD_7_0_BASE OPENBSD_7_1_BASE OPENBSD_7_2_BASE
|
#
1.12 |
|
04-Nov-2016 |
miod |
Replace all uses of magic numbers when operating on OPENSSL_ia32_P[] by meaningful constants in a private header file, so that reviewers can actually get a chance to figure out what the code is attempting to do without knowing all cpuid bits.
While there, turn it from an array of two 32-bit ints into a properly aligned 64-bit int.
Use of OPENSSL_ia32_P is now restricted to the assembler parts. C code will now always use OPENSSL_cpu_caps() and check for the proper bits in the whole 64-bit word it returns.
i386 tests and ok jsing@
|
#
1.11 |
|
02-Jun-2014 |
deraadt |
A few months back there was a big community fuss regarding direct-use of the intel RDRAND instruction. Consensus was RDRAND should probably only be used as an additional source of entropy in a mixer.
Guess which library bends over backwards to provide easy access to RDRAND? Yep. Guess which applications are using this support? Not even one... but still, this is being placed as a trap for someone.
Send this support straight to the abyss. ok kettenis
|
#
1.10 |
|
24-Apr-2014 |
tedu |
repair missing semicolon. from Ian Mcwilliam
|
#
1.9 |
|
23-Apr-2014 |
miod |
Don't bother generating win64 assembly prologue.
|
#
1.8 |
|
17-Apr-2014 |
miod |
Remove oh-so-important-from-a-security-pov OpenSSL_rtdsc() function.
|
#
1.7 |
|
17-Apr-2014 |
miod |
Ok, there was a need for OPENSSL_cleanse() instead of bzero() to prevent supposedly smart compilers from optimizing memory cleanups away. Understood.
Ok, in case of an hypothetically super smart compiler, OPENSSL_cleanse() had to be convoluted enough for the compiler not to recognize that this was actually bzero() in disguise. Understood.
But then why there had been optimized assembler versions of OPENSSL_cleanse() is beyond me. Did someone not trust the C obfuscation?
|
#
1.6 |
|
13-Apr-2014 |
miod |
Merge conflicts; remove MacOS, Netware, OS/2, VMS and Windows build machinery.
|
#
1.5 |
|
31-Oct-2012 |
kettenis |
On amd64 OPENSSL_cpuid_setup and OPENSSL_ia32cap_P are now hidden so we don't have to go through the PLT/GOT to get at them anymore. In fact going through the GOT now fails since we no longer have a GOT entry for OPENSSL_ia32cap_P.
Fixes the problem spotted by jasper@ and sthen@. Based on a diff from mikeb@ who did most of the actual work of tracking down the issue.
ok millert@, mikeb@
|
#
1.4 |
|
13-Oct-2012 |
djm |
resolve conflicts
|
#
1.3 |
|
01-Oct-2010 |
djm |
resolve conflicts, fix local changes
|
#
1.2 |
|
19-Sep-2008 |
otto |
fix some cause of bad TEXTREL on i386 and amd64 - global function calls in .init sections (diff makes them via PLT) - calls to global functions in aes-586.S (made static or local) - global variable accesses in rc4-x86_64.S (now made via GOT) from djm@large; ok miod@
|
#
1.1 |
|
06-Sep-2008 |
djm |
branches: 1.1.1; Initial revision
|
#
1.15 |
|
25-Apr-2023 |
deraadt |
Add endbr64 where needed by inspection. Passes regresson tests. ok jsing, and kind of tb an earlier version
|
#
1.14 |
|
04-Apr-2023 |
anton |
A refactoring back in 2016 in which magic numbers where extracted into named constants accidentally dropped an instruction causing detection of eXtended operations (XOP) on AMD hardware to break.
ok miod@ tb@
|
Revision tags: OPENBSD_7_3_BASE
|
#
1.13 |
|
17-Jan-2023 |
miod |
Remove non-visible and unused OPENSSL_wipe_cpu and OPENSSL_atomic_add interfaces, and remove empty assembly OPENSSL_cpuid_setup routines - the default empty C fallback will work as good.
ok jsing@
|
Revision tags: OPENBSD_6_1_BASE OPENBSD_6_2_BASE OPENBSD_6_3_BASE OPENBSD_6_4_BASE OPENBSD_6_5_BASE OPENBSD_6_6_BASE OPENBSD_6_7_BASE OPENBSD_6_8_BASE OPENBSD_6_9_BASE OPENBSD_7_0_BASE OPENBSD_7_1_BASE OPENBSD_7_2_BASE
|
#
1.12 |
|
04-Nov-2016 |
miod |
Replace all uses of magic numbers when operating on OPENSSL_ia32_P[] by meaningful constants in a private header file, so that reviewers can actually get a chance to figure out what the code is attempting to do without knowing all cpuid bits.
While there, turn it from an array of two 32-bit ints into a properly aligned 64-bit int.
Use of OPENSSL_ia32_P is now restricted to the assembler parts. C code will now always use OPENSSL_cpu_caps() and check for the proper bits in the whole 64-bit word it returns.
i386 tests and ok jsing@
|
#
1.11 |
|
02-Jun-2014 |
deraadt |
A few months back there was a big community fuss regarding direct-use of the intel RDRAND instruction. Consensus was RDRAND should probably only be used as an additional source of entropy in a mixer.
Guess which library bends over backwards to provide easy access to RDRAND? Yep. Guess which applications are using this support? Not even one... but still, this is being placed as a trap for someone.
Send this support straight to the abyss. ok kettenis
|
#
1.10 |
|
24-Apr-2014 |
tedu |
repair missing semicolon. from Ian Mcwilliam
|
#
1.9 |
|
23-Apr-2014 |
miod |
Don't bother generating win64 assembly prologue.
|
#
1.8 |
|
17-Apr-2014 |
miod |
Remove oh-so-important-from-a-security-pov OpenSSL_rtdsc() function.
|
#
1.7 |
|
17-Apr-2014 |
miod |
Ok, there was a need for OPENSSL_cleanse() instead of bzero() to prevent supposedly smart compilers from optimizing memory cleanups away. Understood.
Ok, in case of an hypothetically super smart compiler, OPENSSL_cleanse() had to be convoluted enough for the compiler not to recognize that this was actually bzero() in disguise. Understood.
But then why there had been optimized assembler versions of OPENSSL_cleanse() is beyond me. Did someone not trust the C obfuscation?
|
#
1.6 |
|
13-Apr-2014 |
miod |
Merge conflicts; remove MacOS, Netware, OS/2, VMS and Windows build machinery.
|
#
1.5 |
|
31-Oct-2012 |
kettenis |
On amd64 OPENSSL_cpuid_setup and OPENSSL_ia32cap_P are now hidden so we don't have to go through the PLT/GOT to get at them anymore. In fact going through the GOT now fails since we no longer have a GOT entry for OPENSSL_ia32cap_P.
Fixes the problem spotted by jasper@ and sthen@. Based on a diff from mikeb@ who did most of the actual work of tracking down the issue.
ok millert@, mikeb@
|
#
1.4 |
|
13-Oct-2012 |
djm |
resolve conflicts
|
#
1.3 |
|
01-Oct-2010 |
djm |
resolve conflicts, fix local changes
|
#
1.2 |
|
19-Sep-2008 |
otto |
fix some cause of bad TEXTREL on i386 and amd64 - global function calls in .init sections (diff makes them via PLT) - calls to global functions in aes-586.S (made static or local) - global variable accesses in rc4-x86_64.S (now made via GOT) from djm@large; ok miod@
|
#
1.1 |
|
06-Sep-2008 |
djm |
branches: 1.1.1; Initial revision
|
#
1.14 |
|
04-Apr-2023 |
anton |
A refactoring back in 2016 in which magic numbers where extracted into named constants accidentally dropped an instruction causing detection of eXtended operations (XOP) on AMD hardware to break.
ok miod@ tb@
|
Revision tags: OPENBSD_7_3_BASE
|
#
1.13 |
|
17-Jan-2023 |
miod |
Remove non-visible and unused OPENSSL_wipe_cpu and OPENSSL_atomic_add interfaces, and remove empty assembly OPENSSL_cpuid_setup routines - the default empty C fallback will work as good.
ok jsing@
|
Revision tags: OPENBSD_6_1_BASE OPENBSD_6_2_BASE OPENBSD_6_3_BASE OPENBSD_6_4_BASE OPENBSD_6_5_BASE OPENBSD_6_6_BASE OPENBSD_6_7_BASE OPENBSD_6_8_BASE OPENBSD_6_9_BASE OPENBSD_7_0_BASE OPENBSD_7_1_BASE OPENBSD_7_2_BASE
|
#
1.12 |
|
04-Nov-2016 |
miod |
Replace all uses of magic numbers when operating on OPENSSL_ia32_P[] by meaningful constants in a private header file, so that reviewers can actually get a chance to figure out what the code is attempting to do without knowing all cpuid bits.
While there, turn it from an array of two 32-bit ints into a properly aligned 64-bit int.
Use of OPENSSL_ia32_P is now restricted to the assembler parts. C code will now always use OPENSSL_cpu_caps() and check for the proper bits in the whole 64-bit word it returns.
i386 tests and ok jsing@
|
#
1.11 |
|
02-Jun-2014 |
deraadt |
A few months back there was a big community fuss regarding direct-use of the intel RDRAND instruction. Consensus was RDRAND should probably only be used as an additional source of entropy in a mixer.
Guess which library bends over backwards to provide easy access to RDRAND? Yep. Guess which applications are using this support? Not even one... but still, this is being placed as a trap for someone.
Send this support straight to the abyss. ok kettenis
|
#
1.10 |
|
24-Apr-2014 |
tedu |
repair missing semicolon. from Ian Mcwilliam
|
#
1.9 |
|
23-Apr-2014 |
miod |
Don't bother generating win64 assembly prologue.
|
#
1.8 |
|
17-Apr-2014 |
miod |
Remove oh-so-important-from-a-security-pov OpenSSL_rtdsc() function.
|
#
1.7 |
|
17-Apr-2014 |
miod |
Ok, there was a need for OPENSSL_cleanse() instead of bzero() to prevent supposedly smart compilers from optimizing memory cleanups away. Understood.
Ok, in case of an hypothetically super smart compiler, OPENSSL_cleanse() had to be convoluted enough for the compiler not to recognize that this was actually bzero() in disguise. Understood.
But then why there had been optimized assembler versions of OPENSSL_cleanse() is beyond me. Did someone not trust the C obfuscation?
|
#
1.6 |
|
13-Apr-2014 |
miod |
Merge conflicts; remove MacOS, Netware, OS/2, VMS and Windows build machinery.
|
#
1.5 |
|
31-Oct-2012 |
kettenis |
On amd64 OPENSSL_cpuid_setup and OPENSSL_ia32cap_P are now hidden so we don't have to go through the PLT/GOT to get at them anymore. In fact going through the GOT now fails since we no longer have a GOT entry for OPENSSL_ia32cap_P.
Fixes the problem spotted by jasper@ and sthen@. Based on a diff from mikeb@ who did most of the actual work of tracking down the issue.
ok millert@, mikeb@
|
#
1.4 |
|
13-Oct-2012 |
djm |
resolve conflicts
|
#
1.3 |
|
01-Oct-2010 |
djm |
resolve conflicts, fix local changes
|
#
1.2 |
|
19-Sep-2008 |
otto |
fix some cause of bad TEXTREL on i386 and amd64 - global function calls in .init sections (diff makes them via PLT) - calls to global functions in aes-586.S (made static or local) - global variable accesses in rc4-x86_64.S (now made via GOT) from djm@large; ok miod@
|
#
1.1 |
|
06-Sep-2008 |
djm |
branches: 1.1.1; Initial revision
|
#
1.13 |
|
17-Jan-2023 |
miod |
Remove non-visible and unused OPENSSL_wipe_cpu and OPENSSL_atomic_add interfaces, and remove empty assembly OPENSSL_cpuid_setup routines - the default empty C fallback will work as good.
ok jsing@
|
Revision tags: OPENBSD_6_1_BASE OPENBSD_6_2_BASE OPENBSD_6_3_BASE OPENBSD_6_4_BASE OPENBSD_6_5_BASE OPENBSD_6_6_BASE OPENBSD_6_7_BASE OPENBSD_6_8_BASE OPENBSD_6_9_BASE OPENBSD_7_0_BASE OPENBSD_7_1_BASE OPENBSD_7_2_BASE
|
#
1.12 |
|
04-Nov-2016 |
miod |
Replace all uses of magic numbers when operating on OPENSSL_ia32_P[] by meaningful constants in a private header file, so that reviewers can actually get a chance to figure out what the code is attempting to do without knowing all cpuid bits.
While there, turn it from an array of two 32-bit ints into a properly aligned 64-bit int.
Use of OPENSSL_ia32_P is now restricted to the assembler parts. C code will now always use OPENSSL_cpu_caps() and check for the proper bits in the whole 64-bit word it returns.
i386 tests and ok jsing@
|
#
1.11 |
|
02-Jun-2014 |
deraadt |
A few months back there was a big community fuss regarding direct-use of the intel RDRAND instruction. Consensus was RDRAND should probably only be used as an additional source of entropy in a mixer.
Guess which library bends over backwards to provide easy access to RDRAND? Yep. Guess which applications are using this support? Not even one... but still, this is being placed as a trap for someone.
Send this support straight to the abyss. ok kettenis
|
#
1.10 |
|
24-Apr-2014 |
tedu |
repair missing semicolon. from Ian Mcwilliam
|
#
1.9 |
|
23-Apr-2014 |
miod |
Don't bother generating win64 assembly prologue.
|
#
1.8 |
|
17-Apr-2014 |
miod |
Remove oh-so-important-from-a-security-pov OpenSSL_rtdsc() function.
|
#
1.7 |
|
17-Apr-2014 |
miod |
Ok, there was a need for OPENSSL_cleanse() instead of bzero() to prevent supposedly smart compilers from optimizing memory cleanups away. Understood.
Ok, in case of an hypothetically super smart compiler, OPENSSL_cleanse() had to be convoluted enough for the compiler not to recognize that this was actually bzero() in disguise. Understood.
But then why there had been optimized assembler versions of OPENSSL_cleanse() is beyond me. Did someone not trust the C obfuscation?
|
#
1.6 |
|
13-Apr-2014 |
miod |
Merge conflicts; remove MacOS, Netware, OS/2, VMS and Windows build machinery.
|
#
1.5 |
|
31-Oct-2012 |
kettenis |
On amd64 OPENSSL_cpuid_setup and OPENSSL_ia32cap_P are now hidden so we don't have to go through the PLT/GOT to get at them anymore. In fact going through the GOT now fails since we no longer have a GOT entry for OPENSSL_ia32cap_P.
Fixes the problem spotted by jasper@ and sthen@. Based on a diff from mikeb@ who did most of the actual work of tracking down the issue.
ok millert@, mikeb@
|
#
1.4 |
|
13-Oct-2012 |
djm |
resolve conflicts
|
#
1.3 |
|
01-Oct-2010 |
djm |
resolve conflicts, fix local changes
|
#
1.2 |
|
19-Sep-2008 |
otto |
fix some cause of bad TEXTREL on i386 and amd64 - global function calls in .init sections (diff makes them via PLT) - calls to global functions in aes-586.S (made static or local) - global variable accesses in rc4-x86_64.S (now made via GOT) from djm@large; ok miod@
|
#
1.1 |
|
06-Sep-2008 |
djm |
branches: 1.1.1; Initial revision
|
Revision tags: OPENBSD_6_1_BASE OPENBSD_6_2_BASE
|
#
1.12 |
|
04-Nov-2016 |
miod |
Replace all uses of magic numbers when operating on OPENSSL_ia32_P[] by meaningful constants in a private header file, so that reviewers can actually get a chance to figure out what the code is attempting to do without knowing all cpuid bits.
While there, turn it from an array of two 32-bit ints into a properly aligned 64-bit int.
Use of OPENSSL_ia32_P is now restricted to the assembler parts. C code will now always use OPENSSL_cpu_caps() and check for the proper bits in the whole 64-bit word it returns.
i386 tests and ok jsing@
|
#
1.11 |
|
02-Jun-2014 |
deraadt |
A few months back there was a big community fuss regarding direct-use of the intel RDRAND instruction. Consensus was RDRAND should probably only be used as an additional source of entropy in a mixer.
Guess which library bends over backwards to provide easy access to RDRAND? Yep. Guess which applications are using this support? Not even one... but still, this is being placed as a trap for someone.
Send this support straight to the abyss. ok kettenis
|
#
1.10 |
|
24-Apr-2014 |
tedu |
repair missing semicolon. from Ian Mcwilliam
|
#
1.9 |
|
23-Apr-2014 |
miod |
Don't bother generating win64 assembly prologue.
|
#
1.8 |
|
17-Apr-2014 |
miod |
Remove oh-so-important-from-a-security-pov OpenSSL_rtdsc() function.
|
#
1.7 |
|
17-Apr-2014 |
miod |
Ok, there was a need for OPENSSL_cleanse() instead of bzero() to prevent supposedly smart compilers from optimizing memory cleanups away. Understood.
Ok, in case of an hypothetically super smart compiler, OPENSSL_cleanse() had to be convoluted enough for the compiler not to recognize that this was actually bzero() in disguise. Understood.
But then why there had been optimized assembler versions of OPENSSL_cleanse() is beyond me. Did someone not trust the C obfuscation?
|
#
1.6 |
|
13-Apr-2014 |
miod |
Merge conflicts; remove MacOS, Netware, OS/2, VMS and Windows build machinery.
|
#
1.5 |
|
31-Oct-2012 |
kettenis |
On amd64 OPENSSL_cpuid_setup and OPENSSL_ia32cap_P are now hidden so we don't have to go through the PLT/GOT to get at them anymore. In fact going through the GOT now fails since we no longer have a GOT entry for OPENSSL_ia32cap_P.
Fixes the problem spotted by jasper@ and sthen@. Based on a diff from mikeb@ who did most of the actual work of tracking down the issue.
ok millert@, mikeb@
|
#
1.4 |
|
13-Oct-2012 |
djm |
resolve conflicts
|
#
1.3 |
|
01-Oct-2010 |
djm |
resolve conflicts, fix local changes
|
#
1.2 |
|
19-Sep-2008 |
otto |
fix some cause of bad TEXTREL on i386 and amd64 - global function calls in .init sections (diff makes them via PLT) - calls to global functions in aes-586.S (made static or local) - global variable accesses in rc4-x86_64.S (now made via GOT) from djm@large; ok miod@
|
#
1.1 |
|
06-Sep-2008 |
djm |
branches: 1.1.1; Initial revision
|