Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
On 18/03/2015 10:14, Matt Caswell wrote: On 18/03/15 07:59, Jakob Bohm wrote: (Resend due to MUA bug sending this to -announce) On 16/03/2015 20:05, Matt Caswell wrote: Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf. These releases will be made available on 19th March. They will fix a number of security defects. The highest severity defect fixed by these releases is classified as high severity. Just for clarity in preparing to use the forthcoming update: Has the 1.0.1m source code been mangled by the script that made it near-impossible to port local changes to 1.0.2, or will it retain the same code formatting as in the rest of the 1.0.1 series? Similarly, will 1.0.0r be mangled or will it retain the same code formatting as in the rest of the 1.0.0 series? Similarly, will 0.9.8zf be mangled or will it retain the same code formatting as in the rest of the 0.9.8 series? I prefer the term improved over mangled! ;-) The answer is, yes, all branches (including 1.0.1, 1.0.0 and 0.9.8) have been reformatted according to the new coding style. It is perfectly possible, if a little fiddly, to reformat your local patches to the new style. I have done so myself for a number of my own patches. I included some outline instructions on how to do it in my recent blog post on the reformat: https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/ Long read, and lots of internal details of how your script doesn't even work for yourown code... However the patch rebasing instructions are *completely useless* for those of us whomaintain private patches against releases tarballs. We *don't* have any of this in a clone of your gitand we *have no way* to access intermediary git steps from your partially botched freeze-reformat-unfreeze-other-work-oopsmorereformat- other-work sequence. I guess each of us will have to spend weeks (or more) manually recreating all our hard work before we can apply whatever security fixes are hidden in tomorrows tarball. And it also seems that it is nearly impossible to turn the changes into a reviewable patch that can be applied to an existing tree, like the various distributions (on and off the vendor-sec lists) will need to. So let's all hope one of the vendors will do your job for you and transform the new releases into patches against the previous tarballs, before the embargo is lifted tomorrow, or soon after. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
On 18/03/15 07:59, Jakob Bohm wrote: (Resend due to MUA bug sending this to -announce) On 16/03/2015 20:05, Matt Caswell wrote: Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf. These releases will be made available on 19th March. They will fix a number of security defects. The highest severity defect fixed by these releases is classified as high severity. Just for clarity in preparing to use the forthcoming update: Has the 1.0.1m source code been mangled by the script that made it near-impossible to port local changes to 1.0.2, or will it retain the same code formatting as in the rest of the 1.0.1 series? Similarly, will 1.0.0r be mangled or will it retain the same code formatting as in the rest of the 1.0.0 series? Similarly, will 0.9.8zf be mangled or will it retain the same code formatting as in the rest of the 0.9.8 series? I prefer the term improved over mangled! ;-) The answer is, yes, all branches (including 1.0.1, 1.0.0 and 0.9.8) have been reformatted according to the new coding style. It is perfectly possible, if a little fiddly, to reformat your local patches to the new style. I have done so myself for a number of my own patches. I included some outline instructions on how to do it in my recent blog post on the reformat: https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/ Regards Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
(Resend due to MUA bug sending this to -announce) On 16/03/2015 20:05, Matt Caswell wrote: Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf. These releases will be made available on 19th March. They will fix a number of security defects. The highest severity defect fixed by these releases is classified as high severity. Just for clarity in preparing to use the forthcoming update: Has the 1.0.1m source code been mangled by the script that made it near-impossible to port local changes to 1.0.2, or will it retain the same code formatting as in the rest of the 1.0.1 series? Similarly, will 1.0.0r be mangled or will it retain the same code formatting as in the rest of the 1.0.0 series? Similarly, will 0.9.8zf be mangled or will it retain the same code formatting as in the rest of the 0.9.8 series? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
On 18/03/15 10:45, Jakob Bohm wrote: However the patch rebasing instructions are *completely useless* for those of us whomaintain private patches against releases tarballs. We *don't* have any of this in a clone of your gitand we *have no way* to access intermediary git steps from your partially botched freeze-reformat-unfreeze-other-work-oopsmorereformat- other-work sequence. There should be no reason why the instructions cannot be adapted to patch files, if that is what you are using. You will still need access to git to do it - but the git repository is publicly accessible. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
We maintain our own derivative of OpenSSL and haven't had any significant issues due to the code reformat. We simply run the reformat script on our downstream derivative. We can then generate patch files of our changes and reapply them to new OpenSSL releases. It was fairly straight forward. IMHO, the code reformat was long overdue. The prior lack of consistent coding style was an abomination, making the code more difficult to read and maintain. Sometimes taking a step forward results in some pain. This was a good investment for the future. +1 for the reformat. On 03/18/2015 06:45 AM, Jakob Bohm wrote: On 18/03/2015 10:14, Matt Caswell wrote: On 18/03/15 07:59, Jakob Bohm wrote: (Resend due to MUA bug sending this to -announce) On 16/03/2015 20:05, Matt Caswell wrote: Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf. These releases will be made available on 19th March. They will fix a number of security defects. The highest severity defect fixed by these releases is classified as high severity. Just for clarity in preparing to use the forthcoming update: Has the 1.0.1m source code been mangled by the script that made it near-impossible to port local changes to 1.0.2, or will it retain the same code formatting as in the rest of the 1.0.1 series? Similarly, will 1.0.0r be mangled or will it retain the same code formatting as in the rest of the 1.0.0 series? Similarly, will 0.9.8zf be mangled or will it retain the same code formatting as in the rest of the 0.9.8 series? I prefer the term improved over mangled! ;-) The answer is, yes, all branches (including 1.0.1, 1.0.0 and 0.9.8) have been reformatted according to the new coding style. It is perfectly possible, if a little fiddly, to reformat your local patches to the new style. I have done so myself for a number of my own patches. I included some outline instructions on how to do it in my recent blog post on the reformat: https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/ Long read, and lots of internal details of how your script doesn't even work for yourown code... However the patch rebasing instructions are *completely useless* for those of us whomaintain private patches against releases tarballs. We *don't* have any of this in a clone of your gitand we *have no way* to access intermediary git steps from your partially botched freeze-reformat-unfreeze-other-work-oopsmorereformat- other-work sequence. I guess each of us will have to spend weeks (or more) manually recreating all our hard work before we can apply whatever security fixes are hidden in tomorrows tarball. And it also seems that it is nearly impossible to turn the changes into a reviewable patch that can be applied to an existing tree, like the various distributions (on and off the vendor-sec lists) will need to. So let's all hope one of the vendors will do your job for you and transform the new releases into patches against the previous tarballs, before the embargo is lifted tomorrow, or soon after. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Forthcoming OpenSSL releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/03/15 19:05, Matt Caswell wrote: Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf. These releases will be made available on 19th March. They will fix a number of security defects. The highest severity defect fixed by these releases is classified as high severity. I have received a number of queries regarding the timing of Thursday's release. To clarify, we are aiming to have the release available sometime between 1100-1500 GMT. Regards Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVCVyPAAoJENnE0m0OYESROvYH/1BdqjzpgiTMhAIYsJjDb0xt eWM5GdqwiATa+1FqvYXN1pa3Wencl0UVAKsUh0tsC/6MaQVSqyUVkpJZNvvwTrqt Fmn8sYrF4vFdGNCWoMWWCm0roW9r7V/BGRJrXol0O6b/t5+QrRkVTlEsHTVi3PKD ujQS5heKS5HPNlZEkhWz+MH3i5RcWx7TVTLVGtsKhIlkc0bM5tSKiynMYQyOhkh2 dLfnNvHGC/g7qIeWg3cGXa4P5Y78SrBvKGj5Bu7IouaT2bC01RfAfYH7pJwpISbZ 3qwwKqGuNF31AC8xBM4CPFU+7MJQtRDtcDzQURHud4Vqn4C/rtmnI0r+tkxDi9I= =99aY -END PGP SIGNATURE- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
Nice, so the extra work is minimal for complete forks of OpenSSL. The extra work is also documented (in a place not linked from the wiki) for those who maintain a git fork of the OpenSSL repository. But I have not yet seen a meaningful recipe for those of us who maintain a traditional set of feature patches against the released tarballs, nicely organized for future contribution. Maybe they want us all to fork OpenSSL :-) On 18/03/2015 13:55, John Foley wrote: We maintain our own derivative of OpenSSL and haven't had any significant issues due to the code reformat. We simply run the reformat script on our downstream derivative. We can then generate patch files of our changes and reapply them to new OpenSSL releases. It was fairly straight forward. IMHO, the code reformat was long overdue. The prior lack of consistent coding style was an abomination, making the code more difficult to read and maintain. Sometimes taking a step forward results in some pain. This was a good investment for the future. +1 for the reformat. On 03/18/2015 06:45 AM, Jakob Bohm wrote: On 18/03/2015 10:14, Matt Caswell wrote: On 18/03/15 07:59, Jakob Bohm wrote: (Resend due to MUA bug sending this to -announce) On 16/03/2015 20:05, Matt Caswell wrote: Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf. These releases will be made available on 19th March. They will fix a number of security defects. The highest severity defect fixed by these releases is classified as high severity. Just for clarity in preparing to use the forthcoming update: Has the 1.0.1m source code been mangled by the script that made it near-impossible to port local changes to 1.0.2, or will it retain the same code formatting as in the rest of the 1.0.1 series? Similarly, will 1.0.0r be mangled or will it retain the same code formatting as in the rest of the 1.0.0 series? Similarly, will 0.9.8zf be mangled or will it retain the same code formatting as in the rest of the 0.9.8 series? I prefer the term improved over mangled! ;-) The answer is, yes, all branches (including 1.0.1, 1.0.0 and 0.9.8) have been reformatted according to the new coding style. It is perfectly possible, if a little fiddly, to reformat your local patches to the new style. I have done so myself for a number of my own patches. I included some outline instructions on how to do it in my recent blog post on the reformat: https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/ Long read, and lots of internal details of how your script doesn't even work for yourown code... However the patch rebasing instructions are *completely useless* for those of us whomaintain private patches against releases tarballs. We *don't* have any of this in a clone of your gitand we *have no way* to access intermediary git steps from your partially botched freeze-reformat-unfreeze-other-work-oopsmorereformat- other-work sequence. I guess each of us will have to spend weeks (or more) manually recreating all our hard work before we can apply whatever security fixes are hidden in tomorrows tarball. And it also seems that it is nearly impossible to turn the changes into a reviewable patch that can be applied to an existing tree, like the various distributions (on and off the vendor-sec lists) will need to. So let's all hope one of the vendors will do your job for you and transform the new releases into patches against the previous tarballs, before the embargo is lifted tomorrow, or soon after. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Solaris 11.2 openssl
I have BMC BladeLogic and recently downloaded a password change script that uses openssl and I am seeing an error message of the script unable for openssl to generate hash for password. Can I attach the script for someone to help me? Thank you, Respectfully //SIGNED// Andy Magaña UNIX Systems Administrator Diligent Contractor, 72nd Air Base Wing Tinker Air Force Base, Oklahoma Commercial: (405) 734-0341 -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of openssl-users-requ...@openssl.org Sent: Tuesday, March 17, 2015 5:30 PM To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Subject: Welcome to the openssl-users mailing list (Digest mode) Welcome to the openssl-users@openssl.org mailing list! To post to this list, send your message to: openssl-users@openssl.org General information about the mailing list is at: https://mta.openssl.org/mailman/listinfo/openssl-users If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://mta.openssl.org/mailman/options/openssl-users/andreas.magana.ctr%40u s.af.mil You can also make such adjustments via email by sending a message to: openssl-users-requ...@openssl.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe without confirmation. It is: monster35 Normally, Mailman will remind you of your openssl.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. smime.p7s Description: S/MIME cryptographic signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] base64 decode in C
Hi, before calling this function, remove any whitespace; Walter smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
The extra work is also documented (in a place not linked from the wiki) for those who maintain a git fork of the OpenSSL repository. I just tossed together https://wiki.openssl.org/index.php/Code_reformatting Found off the main page, https://wiki.openssl.org/index.php/Main_Page#Internals_and_Development But I have not yet seen a meaningful recipe for those of us who maintain a traditional set of feature patches against the released tarballs, nicely organized for future contribution. Folks had months of warning that this was going to happen. And, frankly, patches did not come flooding into the team. But I hope the above link helps. /r$ ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] base64 decode in C
Hi Dave and Walter,
Thanks for our reply.
I'm not doing anything different for the ssh pubkey. I'm able to decode it
using the openssl enc -base64 -d -A command. But not using the C program.
Attaching my entire code here. After getting the base64 decoded I'm
calculating the MD5 sum and printing it. This works for a regular string
but not for SSH pubkey.
Thanks again.
--Prashant
On 18 March 2015 at 18:04, Walter H. walte...@mathemainzel.info wrote:
Hi,
before calling this function,
remove any whitespace;
Walter
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
#include openssl/md5.h
#include openssl/sha.h
#include openssl/hmac.h
#include openssl/evp.h
#include openssl/bio.h
#include openssl/buffer.h
#include string.h
#include stdio.h
char *b64_decode(unsigned char *input, int length);
char* md5_digest(char *string);
int main()
{
char *str = B3NzaC1yc2EDAQABAAABAQC/KdcFv09+f+tJK9IZ8I+L0zG7dUINClI5v8FlHJsBPSM3DDO2DpwIg/KqZKCRH9y6lEO+QAJt2DTEq/LBZcBUCdeiX1TXPFRorX+VdZigj7av/S/UHkq2EH6hfkJB3oLA5ZOZioMOAuDv1ng/DE4pRBr+KZ2oVhGjf3wa0hWi21vTZqb3s7vh+bPf6C2eUmAQJKHvFhtBK8Xx7FxN0b7igsGbk7ObwcItfMxdzkMvuiuU/UnthFVpa8wZIObFDi3MxJuf3/R+h6R1lFMvEIrU6CWRupS7Pqkm4X3qWQfhAWbdgdbD5KAk5JLA2eWIPQQA5Uay5CeH+GXz8gCa4zaz;
printf(Base64 decoded string is : %s\n, b64_decode(str, strlen(str))); // This should print binary for a ssh key.
printf(MD5 Sum of the decoded string is : %s\n, md5_digest(b64_decode(str, strlen(str;
return 0;
}
char *b64_decode(unsigned char *input, int length)
{
BIO *b64, *bmem;
char *buffer = (char *)malloc(length);
memset(buffer, 0, length);
b64 = BIO_new(BIO_f_base64());
bmem = BIO_new_mem_buf((void*)input, length);
bmem = BIO_push(b64, bmem);
BIO_set_flags(bmem, BIO_FLAGS_BASE64_NO_NL);
BIO_read(bmem, buffer, length);
BIO_free_all(bmem);
return buffer;
}
char* md5_digest(char *string)
{
int i;
unsigned char result[MD5_DIGEST_LENGTH];
// Length of MD5 signature is 32 !
char * md5_sig = (char *) malloc(33);
MD5(string, strlen(string), result);
// output
for(i = 0; i MD5_DIGEST_LENGTH; i++){
sprintf( md5_sig[i*2], %02x, result[i]);
}
return md5_sig;
}
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] base64 decode in C
Please refer to Dave Thompson's answer, it describes your problem. On 18/03/2015 16:08, Prashant Bapat wrote: Hi Dave and Walter, Thanks for our reply. I'm not doing anything different for the ssh pubkey. I'm able to decode it using the openssl enc -base64 -d -A command. But not using the C program. Attaching my entire code here. After getting the base64 decoded I'm calculating the MD5 sum and printing it. This works for a regular string but not for SSH pubkey. Thanks again. --Prashant Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
Thanks for the three line upgracde recipe in https://wiki.openssl.org/index.php/Code_reformatting It's as simple as you stated, indeed. The reformatting was a good thing to do. Also, it makes sense to me to apply it to all stable branches uniformly, in order to simplify cross-branch merging. msp On 03/18/2015 04:32 PM, Salz, Rich wrote: The extra work is also documented (in a place not linked from the wiki) for those who maintain a git fork of the OpenSSL repository. I just tossed together https://wiki.openssl.org/index.php/Code_reformatting Found off the main page, https://wiki.openssl.org/index.php/Main_Page#Internals_and_Development But I have not yet seen a meaningful recipe for those of us who maintain a traditional set of feature patches against the released tarballs, nicely organized for future contribution. Folks had months of warning that this was going to happen. And, frankly, patches did not come flooding into the team. But I hope the above link helps. /r$ ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] base64 decode in C
I believe the SSH pubkey is binary data, not ASCII, so strlen() will not work on it if it has embedded NUL chars. As Dave Thompson suggested, instead of strlen(), use the length returned from BIO_read. From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Prashant Bapat Sent: Wednesday, March 18, 2015 8:08 AM To: openssl-users Subject: Re: [openssl-users] base64 decode in C Hi Dave and Walter, Thanks for our reply. I'm not doing anything different for the ssh pubkey. I'm able to decode it using the openssl enc -base64 -d -A command. But not using the C program. Attaching my entire code here. After getting the base64 decoded I'm calculating the MD5 sum and printing it. This works for a regular string but not for SSH pubkey. Thanks again. --Prashant On 18 March 2015 at 18:04, Walter H. walte...@mathemainzel.infomailto:walte...@mathemainzel.info wrote: Hi, before calling this function, remove any whitespace; Walter ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] base64 decode in C
Hi,
Most likely this has been answered before, please bear with me.
I'm trying to use the base64 decode function in C. Below is the function.
char *b64_decode(unsigned char *input, int length)
{
BIO *b64, *bmem;
char *buffer = (char *)malloc(length);
memset(buffer, 0, length);
b64 = BIO_new(BIO_f_base64());
bmem = BIO_new_mem_buf((void*)input, length);
bmem = BIO_push(b64, bmem);
BIO_set_flags(bmem, BIO_FLAGS_BASE64_NO_NL);
BIO_read(bmem, buffer, length);
BIO_free_all(bmem);
return buffer;
}
This works well for simple b64 encoded strings like hello world! etc. But
when I want to b64 decode the contents of a SSH public key, it fails.
Returns nothing.
What I'm trying to get to is the SSH public key fingerprint which is the
MD5 hash of the base64 decoded part of the public key.
This decodes fine.
dGhpcyBpcyBhd2Vzb21lCg== : this is awesome
This does not.
B3NzaC1yc2EDAQABAAABAQC/KdcFv09+f+tJK9IZ8I+L0zG7dUINClI5v8FlHJsBPSM3DDO2DpwIg/KqZKCRH9y6lEO+QAJt2DTEq/LBZcBUCdeiX1TXPFRorX+VdZigj7av/S/UHkq2EH6hfkJB3oLA5ZOZioMOAuDv1ng/DE4pRBr+KZ2oVhGjf3wa0hWi21vTZqb3s7vh+bPf6C2eUmAQJKHvFhtBK8Xx7FxN0b7igsGbk7ObwcItfMxdzkMvuiuU/UnthFVpa8wZIObFDi3MxJuf3/R+h6R1lFMvEIrU6CWRupS7Pqkm4X3qWQfhAWbdgdbD5KAk5JLA2eWIPQQA5Uay5CeH+GXz8gCa4zaz
What I'm I doing wrong ?
Btw in the command line both decode. Using echo string | openssl enc
-base64 -d -A
Any help appreciated.
Thanks in advance.
--Prashant
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
Hello, Here is a recipe to guide you through the reformatting. It worked nicely for me. I wrote a small bash shell script which helped me do the bulk conversion, see attachment Hope you'll find this information helpful. In following I briefly describe the steps how you can 1) get your patches into git (if not yet done) 2) do the reformatting of the commits in git, with the help of my script 3) rebase your patches to the current release 4) recreate the patches using 'git format-patch' If your patches are already maintained in a git repository, you may skip step 1) 1) If you only have patches, it's a good idea to get your own clone of the git repository git clone git://git.openssl.org/openssl.git cd openssl now create a branch off the vanilla release to which your patches apply (say, OpenSSL 1.0.1k) git checkout -b mypatches OpenSSL_1_0_1k apply your patches one after the other, creating a single commit for each with meaningful commit messages (If you don't know how to do this in git, you may want to see http://git-scm.com/doc) 2) Now we assume that a) you already have an OpenSSL git repository b) your patches are on a branch called 'mypatches', which were branched from one of the stable branches before the reformatting (say OpenSSL_1_0_1-stable) c) your working copy is clean (no local changes or untracked files) d) you're running linux (if not, get yourself a Linux VM) The attached script shows an example of how to automate the procedure of reformatting every single commit on your branch and recommitting it. It contains a lot of comments to explain what it is doing. PLEASE READ THE COMMENTS CAREFULLY BEFORE RUNNING THE SCRIPT! You just have to set the two variables 'branch' and 'upstream' at the beginning of the script (marked 'todo') to the name of your branch and its upstream branch, respectively. 3) After the script has succeeded, you can rebase your reformatted branch to the head of the stable branch (or to the tag of the most recent release), e.g. git checkout -b mypatches-reformatted mypatches-post-auto-reformat git rebase OpenSSL_1_0_1-stable 4) Now you can have git recreate your patches automatically with a single command: git format-patch $(git merge-base HEAD OpenSSL_1_0_1-stable)..HEAD [5) Now you can keep using the git repository to manage new patches. Due the rebasing capabilites of git, your patches will always be up to date ] DISCLAIMER The script is not 100% fool-proof, it's a demonstration which may serve as a starting point for you. In particular, there is no error recovery and no guarantee, if there are any conflicts or errors in the middle of the reformating procedure. So you'll better try it on a copy of your git repository first. -Ursprüngliche Nachricht- Von: openssl-users [mailto:openssl-users-boun...@openssl.org] Im Auftrag von Jakob Bohm Gesendet: Mittwoch, 18. März 2015 15:39 An: openssl-users@openssl.org Betreff: Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases Nice, so the extra work is minimal for complete forks of OpenSSL. The extra work is also documented (in a place not linked from the wiki) for those who maintain a git fork of the OpenSSL repository. But I have not yet seen a meaningful recipe for those of us who maintain a traditional set of feature patches against the released tarballs, nicely organized for future contribution. Maybe they want us all to fork OpenSSL :-) On 18/03/2015 13:55, John Foley wrote: We maintain our own derivative of OpenSSL and haven't had any significant issues due to the code reformat. We simply run the reformat script on our downstream derivative. We can then generate patch files of our changes and reapply them to new OpenSSL releases. It was fairly straight forward. IMHO, the code reformat was long overdue. The prior lack of consistent coding style was an abomination, making the code more difficult to read and maintain. Sometimes taking a step forward results in some pain. This was a good investment for the future. +1 for the reformat. On 03/18/2015 06:45 AM, Jakob Bohm wrote: On 18/03/2015 10:14, Matt Caswell wrote: On 18/03/15 07:59, Jakob Bohm wrote: (Resend due to MUA bug sending this to -announce) On 16/03/2015 20:05, Matt Caswell wrote: Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf. These releases will be made available on 19th March. They will fix a number of security defects. The highest severity defect fixed by these releases is classified as high severity. Just for clarity in preparing to use the forthcoming update: Has the 1.0.1m source code been mangled by the script that made it near-impossible to port local changes to 1.0.2, or will it retain the same code formatting as in the rest of the 1.0.1 series?
[openssl-users] FIPS 140-2 hostage rescue underway
As always, if you don't know or care what FIPS 140-2 is then count yourself lucky and move on (in this case, count yourself *very* lucky). We have -- we think -- a workaround for the hostage issue that was blocking the addition of new platforms to the OpenSSL FIPS module validation via change letter updates. That issue impacted several platform updates that were already in process (the hostages). The workaround is messy, ugly, and complex in the finest tradition of bureaucratic molehill-to-mountain obfuscation. An attempt to describe it can be found here: http://openssl.com/fips/ransom.html The TL;DR is that the current #1747 validation becomes three validations that share the same OpenSSL FIPS module (more or less). So, actual use and deployment of the FIPS module will be the same as before and all previously tested platforms remain available (that's the big win). Compliance paperwork will require some careful attention to the multiple validations which will overlap the same module (the downside). Confusion is inevitable, feel free to post questions to this list. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] base64 decode in C
On 18.03.2015 16:08, Prashant Bapat wrote: printf(Base64 decoded string is : %s\n, b64_decode(str, strlen(str))); // This should print binary for a ssh key. not really, because the return of b64_decode is not a C string; and the format specfier %s expects a C string; smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
