Re: OpenSSL Logo
Right, there is no 3D. Regards, Paul Yang > On Feb 27, 2020, at 6:54 PM, Tomas Mraz wrote: > > On Thu, 2020-02-27 at 11:28 +0100, Matthias St. Pierre wrote: >> Thank you for the clarification, Mark. >> >> So this means we have some artistic freedom in choosing the logo? >> >> Personally, I'm not sure whether we really should aim at restoring >> the historic logo. IMHO this ornate font with 3D appearance reminds >> me of the nineties and has slightly gone out of style. Just take a >> look >> how the Google logo changed over time [1], for example. >> >> I think it's time for a more modern layout. Let's have a competition. > > I like the logo as sent by Paul. There is no "3D appearance" in it. > > -- > Tomáš Mráz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] >
Re: OpenSSL Logo (was: New GitHub Project Landing Page)
This reminds me that it seems the lost of the original logo caused the new logo on the new website. (No high resolution source image) Regards, Paul Yang > On Feb 27, 2020, at 5:52 PM, Tomas Mraz wrote: > > On Thu, 2020-02-27 at 10:31 +0100, Matthias St. Pierre wrote: >> >> The openssl.svg was chosen to match the current logo at >> >> https://www.openssl.org/ >> >> as close as possible. According to the style sheet, the font of the >> logo >> is HelveticaNeue-Light. >> >> https://github.com/openssl/web/blob/master/inc/screen.css#L131-L158 >> >> While I'm not opposed to brush up the OpenSSL logo, I think this >> can't >> be done simply be replacing it on the fly. I think this requires a >> general >> discussion among the team members and finally an OMC decision, >> and shouldn't be rushed. Because after all, the shape of the logo is >> an >> essential part of the OpenSSL 'trade mark'. >> >> If we we want to brush up the Logo, we should give everybody time to >> come up >> with proposals and then have an open contest, ideally among all >> committers, >> not only OMC or OTC. (And you can be sure, I will come up with a >> proposal ;-) ) >> >> Finally, the OMC can run a vote, for example whether to pick the >> winner of the >> contest or to leave the logo as it is. > > The logo (attached) that Paul Yang created is matching the logo on the > old OpenSSL website. You can see it here for example: > > https://j3pd.files.wordpress.com/2011/08/openssl.jpg > <https://j3pd.files.wordpress.com/2011/08/openssl.jpg> > > I do not know how the current logo on the web was created or if there > was any formal decision process applied but I would expect it was > created just as an approximation of the original logo without using a > picture. > > -- > Tomáš Mráz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > >
Re: OpenSSL Logo (was: New GitHub Project Landing Page)
As far as I know the original intended logo is not the HelveticalNeue-Light one (the one currently on openssl.org). Long time ago someone has designed a logo with the font similar to the one I printed on the stickers and that logo has also been used in some other places during that time. I think you can still found that version on Goolge. But the original high resolution version of that logo was lost for unknown reason. So the openssl.org <http://openssl.org/> has no choice to use a text-based version of the logo, with the HelveticalNeue-Light font. The logo in the ‘.ai’ file I mentioned previously is actually one reissued version of the 'correct-but-lost’ version. It was created by ‘hand-imitating’ the low-resolution image files found on Google…(that was in around 2018 IIRC and I asked a BaishanCloud UED guy to help on the reissue task ;-). Regards, Paul Yang > On Feb 27, 2020, at 5:31 PM, Matthias St. Pierre > wrote: > > > The openssl.svg was chosen to match the current logo at > > https://www.openssl.org/ <https://www.openssl.org/> > > as close as possible. According to the style sheet, the font of the logo > is HelveticaNeue-Light. > > https://github.com/openssl/web/blob/master/inc/screen.css#L131-L158 > <https://github.com/openssl/web/blob/master/inc/screen.css#L131-L158> > > While I'm not opposed to brush up the OpenSSL logo, I think this can't > be done simply be replacing it on the fly. I think this requires a general > discussion among the team members and finally an OMC decision, > and shouldn't be rushed. Because after all, the shape of the logo is an > essential part of the OpenSSL 'trade mark'. > > If we we want to brush up the Logo, we should give everybody time to come up > with proposals and then have an open contest, ideally among all committers, > not only OMC or OTC. (And you can be sure, I will come up with a proposal > ;-) ) > > Finally, the OMC can run a vote, for example whether to pick the winner of the > contest or to leave the logo as it is. > > Regards, > > Matthias > > > > On 27.02.20 09:58, Paul Yang wrote: >> Sent >> >> Regards, >> >> Paul Yang >> >>> >>>Dr. Matthias St. Pierre >>> >>> Senior Software Engineer >>> matthias.st.pie...@ncp-e.com >>> Phone: +49 911 9968-0 >>> www.ncp-e.com >>> >>> Follow us on: Facebook <https://www.facebook.com/NCPengineering> | Twitter >>> <https://twitter.com/NCP_engineering> | Xing >>> <https://www.xing.com/companies/ncpengineeringgmbh> | YouTube >>> <https://www.youtube.com/user/NCPengineeringGmbH> | LinkedIn >>> <http://www.linkedin.com/company/ncp-engineering-inc.?trk=cws-cpw-coname-0-0> >>> >>> Headquarters Germany: NCP engineering GmbH • Dombuehler Str. 2 • 90449 • >>> Nuremberg >>> North American HQ: NCP engineering Inc. • 678 Georgia Ave. • Sunnyvale, CA >>> 94085 >>> East Coast Office: NCP engineering Inc. • 601 Cleveland Str., Suite 501-25 >>> • Clearwater, FL 33755 >>> >>> Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate >>> Dietrich >>> Registry Court: Lower District Court of Nuremberg >>> Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE >>> 133557619 >>> >>> This e-mail message including any attachments is for the sole use of the >>> intended recipient(s) and may contain privileged or confidential >>> information. Any unauthorized review, use, disclosure or distribution is >>> prohibited. If you are not the intended recipient, please immediately >>> contact the sender by reply e-mail and delete the original message and >>> destroy all copies thereof. >>> >>> >>> <https://www.ncp-e.com/de/aktuelles/events/veranstaltungen> >>> <https://www.ncp-e.com/de/aktuelles/events/veranstaltungen> >>> >>> On Feb 27, 2020, at 3:15 PM, Tomas Mraz >> <mailto:tm...@redhat.com>> wrote: >>> >>> Could you, please, send me the .ai file? I'll try converting it. Is the >>> font freely available? >>> >>> Tomas >>> >>> On Thu, 2020-02-27 at 14:17 +0800, Paul Yang wrote: >>>> The logo could be changed to the 'correct-font' version -as the one >>>> printed on the stickers I brought to Nuremberg >>>> >>>> I have an '.ai’ image file at hand an I think someone needs to figure >>>> how to extract the image then include it in the markdown file... >>>> >>>> Regards, >>>> >>>> Paul Yang >
Re: New GitHub Project Landing Page
Sent Regards, Paul Yang > On Feb 27, 2020, at 3:15 PM, Tomas Mraz wrote: > > Could you, please, send me the .ai file? I'll try converting it. Is the > font freely available? > > Tomas > > On Thu, 2020-02-27 at 14:17 +0800, Paul Yang wrote: >> The logo could be changed to the 'correct-font' version -as the one >> printed on the stickers I brought to Nuremberg >> >> I have an '.ai’ image file at hand an I think someone needs to figure >> how to extract the image then include it in the markdown file... >> >> Regards, >> >> Paul Yang >> >>> On Feb 27, 2020, at 5:12 AM, Dmitry Belyavsky >>> wrote: >>> >>> Looks great! Many thanks for your efforts! >>> >>> On Wed, Feb 26, 2020 at 11:13 PM Dr. Matthias St. Pierre < >>> matthias.st.pie...@ncp-e.com> wrote: >>>> The OpenSSL Project GitHub has a new landing page: >>>> >>>> https://github.com/openssl/openssl >>>> >>>> Scroll down. Enjoy. >>>> >>>> >>>> Matthias >>>> >>>> >>> >>> >>> -- >>> SY, Dmitry Belyavsky >> >> > -- > Tomáš Mráz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] >
Re: New GitHub Project Landing Page
The logo could be changed to the 'correct-font' version -as the one printed on the stickers I brought to Nuremberg I have an '.ai’ image file at hand an I think someone needs to figure how to extract the image then include it in the markdown file... Regards, Paul Yang > On Feb 27, 2020, at 5:12 AM, Dmitry Belyavsky wrote: > > Looks great! Many thanks for your efforts! > > On Wed, Feb 26, 2020 at 11:13 PM Dr. Matthias St. Pierre > mailto:matthias.st.pie...@ncp-e.com>> wrote: > The OpenSSL Project GitHub has a new landing page: > > https://github.com/openssl/openssl <https://github.com/openssl/openssl> > > Scroll down. Enjoy. > > > Matthias > > > > > -- > SY, Dmitry Belyavsky
Re: Flaw in our process for dealing with trivial changes
It seems we have the same thoughts... Regards, Paul Yang > On Dec 12, 2019, at 5:36 PM, Dr Paul Dale wrote: > > I agree that there is a possible flaw in the workflow. What’s saved us so > far is that new contributors don’t generally include the "CLA: trivial" line > or put it in the GitHub text. > > Could we have a “trivial” tag that is added whenever the "CLA: trivial" line > is present? Better would be to add it only if the submitter doesn’t have a > CLA on file but either works. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 12 Dec 2019, at 7:20 pm, Matt Caswell > <mailto:m...@openssl.org>> wrote: >> >> I notice that PR 10594 (Add support for otherName:NAIRealm in output) >> got merged yesterday: >> https://github.com/openssl/openssl/pull/10594 >> <https://github.com/openssl/openssl/pull/10594> >> >> The commit description contained "CLA: trivial" and so the "hold: cla >> required" label was not automatically applied to the PR. But the >> discussion in the PR suggested a CLA should be submitted. But it got >> merged anyway! Fortunately the CLA had already been processed - just not >> noted in the PR. So, in this case, it makes no difference. >> >> I think this points to a possible flaw in our workflow for dealing with >> trivial changes. Because the "CLA: trivial" header suppresses the "hold: >> cla required" label and the git hooks don't complain when commits get >> pushed with the "CLA: trivial" header and no CLA on file, it seems >> possible to me that we could push commit all the way through the process >> without the reviewers even realising that the author is claiming >> triviality on the commit. >> >> Not sure what the solution to that is. >> >> Matt > signature.asc Description: Message signed with OpenPGP
Re: Flaw in our process for dealing with trivial changes
Would it be better if 'CLA: trivial’ is in the commit message but no CLA on file, then a new label like ’warn: no CLA but trivial’ is added? This can inform the committer who will merge the PR for the CLA condition of the commits. Regards, Paul Yang > On Dec 12, 2019, at 5:29 PM, Dmitry Belyavsky wrote: > > Dear Matt, > > As > - the contributor agreed to sign the CLA and > - there was a mark that CLA is signed and > - all the necessary approves were present > I decided that there is no problem to merge. > > BTW, I am not sure the PR was trivial enough. > > Anyway, the responsibility was mine, not the git one :) > > > On Thu, Dec 12, 2019 at 12:20 PM Matt Caswell <mailto:m...@openssl.org>> wrote: > I notice that PR 10594 (Add support for otherName:NAIRealm in output) > got merged yesterday: > https://github.com/openssl/openssl/pull/10594 > <https://github.com/openssl/openssl/pull/10594> > > The commit description contained "CLA: trivial" and so the "hold: cla > required" label was not automatically applied to the PR. But the > discussion in the PR suggested a CLA should be submitted. But it got > merged anyway! Fortunately the CLA had already been processed - just not > noted in the PR. So, in this case, it makes no difference. > > I think this points to a possible flaw in our workflow for dealing with > trivial changes. Because the "CLA: trivial" header suppresses the "hold: > cla required" label and the git hooks don't complain when commits get > pushed with the "CLA: trivial" header and no CLA on file, it seems > possible to me that we could push commit all the way through the process > without the reviewers even realising that the author is claiming > triviality on the commit. > > Not sure what the solution to that is. > > Matt > > > -- > SY, Dmitry Belyavsky signature.asc Description: Message signed with OpenPGP
Re: Being socially aware
I think this highly depends on a person’s character - sensitive or insensitive for instance. Communicating online makes it even harder to know one’s emotion behind the screens/comments. I am kinda agree with Richard that the issues with label "good first issue” could be treated a little more cautious to encourage more new contributors - suppose passing the regular review process of course. > On Sep 17, 2019, at 3:53 PM, Richard Levitte wrote: > > You forget that this is done in public, i.e. others are looking at how > we treat those who do come forward and submit code to some bite size > issue. So while @agnosticdev may have enough skin on his nose, > onlookers that are considering whether they should contribute may not. > > On Tue, 17 Sep 2019 09:04:21 +0200, > Dr. Matthias St. Pierre wrote: >> >> I appreciate your concerns Richard, but I believe they are unwarranted in >> this >> case fortunately. >> >> First, my impression is that the discussion between was objective all the >> time >> and far from being heated up with emotions. >> >> Second, looking at the profile of the contributor, one can assert that he >> might >> be relatively new to our project, but he is certainly experienced in Open >> Source >> development. So I wouldn't worry too much about his feelings 😉 >> >> Regards, >> Matthias >> > -- > Richard Levitte levi...@openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ Regards, Paul Yang signature.asc Description: Message signed with OpenPGP
Re: Update
> On May 22, 2019, at 10:16, Salz, Rich wrote: > >>> I'd be opposed to this last option without IANA/IETF being on board. By >>> doing so >> we are effectively no longer compliant with IETF TLS since we're using >> certain >> codepoints and version numbers to mean things that IETF/IANA have no >> visibility >> of, i.e. we would be doing exactly what Rich was worried about. I don't see >> IANA/IETF doing this anytime soon. >> >> For the most part, getting IANA on board requires someone in authority email >> to tls-regis...@iana.org asking for code points and pointing to their spec. > >’someone in authority’ here means the author of the spec who is asking for > code points? > > > Yes. Or someone involved with the spec. Hmmm, that would be someone involved in GM/T 0024... >
Re: Update
> On May 21, 2019, at 22:13, Salz, Rich wrote: > > >> I'd be opposed to this last option without IANA/IETF being on board. By >> doing so >we are effectively no longer compliant with IETF TLS since we're using > certain >codepoints and version numbers to mean things that IETF/IANA have no > visibility >of, i.e. we would be doing exactly what Rich was worried about. I don't see >IANA/IETF doing this anytime soon. > > For the most part, getting IANA on board requires someone in authority email > to tls-regis...@iana.org asking for code points and pointing to their spec. ’someone in authority’ here means the author of the spec who is asking for code points? >
Re: Update
> On May 21, 2019, at 06:20, Matt Caswell wrote: > > > On 20/05/2019 20:01, Kurt Roeckx wrote: >> On Mon, May 20, 2019 at 10:21:45AM -0700, Paul Yang wrote: >>> >>> The Chinese modified TLS protocol is not intended to interoperate with any >>> other TLS protocols. The cipher suites defined in this protocol should not >>> be used with the standard IETF TLS. So I guess what Matt said would be >>> feasible to do. But in reality, users may want to have a combination of >>> both IETF TLS and Chinese TLS together when he launches a TLS server or >>> client, to have the auto-selection functionality if a TLS client comes in. >>> So the way of implementation would be tricky... >> >> So I think there are 3 options: >> - You use TLS, not some Chinese variant, and add things like Chinese >> ciphers to it. > > That would be fine but my understanding is that the Chinese government mandate > this particular Chinese variant in some situations - so we'd also have to > change > government policy which doesn't seem very likely ;-) You are right. There is currently no official Chinese national standards that define cipher suites for IETF TLS yet. > >> - Use something that's not TLS at all, a Chinese variant, and >> don't support both protocols on the same port. > > If we decide to add support for the Chinese variant, then this would be my > preferred way of doing it. > >> - Support both on the same port. This will require coordination >> with IANA and/or IETF. > > I'd be opposed to this last option without IANA/IETF being on board. By doing > so > we are effectively no longer compliant with IETF TLS since we're using certain > codepoints and version numbers to mean things that IETF/IANA have no > visibility > of, i.e. we would be doing exactly what Rich was worried about. I don't see > IANA/IETF doing this anytime soon. > > Matt >
Re: Update
> On May 20, 2019, at 07:49, Matt Caswell wrote: > > > On 20/05/2019 15:23, Salz, Rich wrote: >>> I don't see it that way. As I understand it this is a completely different >>protocol to standard TLS. >> >> That's an interesting point, but ... they use the SSL "name." > > Which isn't even an IETF name...the IETF call it TLS ;-) > >>> It is not intended to interoperate with it in any way. >> Is that true? I didn't look closely at the protocol changes, but maybe >> you're right. On the other hand, if so, then why keep the existing IETF >> numbers? > > > That was my understanding. > > But perhaps Paul Yang can confirm? The Chinese modified TLS protocol is not intended to interoperate with any other TLS protocols. The cipher suites defined in this protocol should not be used with the standard IETF TLS. So I guess what Matt said would be feasible to do. But in reality, users may want to have a combination of both IETF TLS and Chinese TLS together when he launches a TLS server or client, to have the auto-selection functionality if a TLS client comes in. So the way of implementation would be tricky... Another problem we are still facing nowadays is actually there *would* even be interoperability issues between Chinese TLS implementations (as we discussed earlier in Vancouver). The GM/T 0024 is not very strict and clear on several details in the protocol thus implementations have freedom to be diverse. So if OpenSSL finally picks up the Chinese TLS, we probably need to make sure the implementation should be widely tested against most Chinese TLS implementations. As what Tim has asked at: https://github.com/openssl/openssl/pull/8910#issuecomment-491964656 <https://github.com/openssl/openssl/pull/8910#issuecomment-491964656> > >>> As a completely different protocol they can use whatever codepoints they >>> want to >>use as they see fit - and there is no conflict with IETF specifications. >> >> If you are correct, then yes I agree. But that makes any OpenSSL >> integration that much harder, doesn't it? Would the project take on the >> work of making things like the apps and tests work? In particular, a new >> global flag saying "tnssl" (or such), and failing to interop with existing >> TLS, checking the modified cipher suites (and disallowing them for real >> TLS), etc. >> >> > Yes, we would have to take care that the two really are separate. > > Matt > >
[openssl-project] Presentation of OpenSSL in China
Hi OpenSSL, I would like to drop this email as a note for you guys (and other people who cares about this project) to know: Yesterday I was invited to an ‘open source and cloud computing’ conference in Beijing to give a speech on OpenSSL. The topic of the presentation was ‘Post-Heartbleed Era of OpenSSL’, which focused on important events happened in the project from 2014 to 2018. I started the speech with a very quick look-back on Heartbleed and then moved to talk about what happened in the project chronologically, including important release (1.0.2, 1.1.0, 1.1.1), important improvements in those releases (code reformat, old code delete, removal of weak ciphers and protocols...), important features (TLSv1.3, new DRBG, SHA-3, ASYNC, STORE…), important policies and community development (license changing, moving to utilize Github, attitudes to crypto algos, last China tour…), and at last I introduced the openssl-book project. The result was great. Tech guys in the audience were excited about the nowadays OpenSSL and they believed the project is becoming better. And even a Chinese local book publisher asked me if it’s possible to publish the Chinese edition of the openssl-book as paper copy in China, and after discussing with some OMC members, we found it’s possible to do so. Of course, that would happen after the book is really finished someday in the future. And I hope some amount of the profit made by selling the book could be returned back to OpenSSL foundation, as a way of helping the project. As far as I know this was the first time that the big picture of OpenSSL was reviewed and discussed in a major, high level China tech conference, in Chinese language. I think there will be videos available online and also articles reporting this presentation in a few days, but since they are all in Chinese, I don’t know if it’s helpful to share them to this list when they are ready. Regards, Paul Yang signature.asc Description: Message signed with OpenPGP ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
