Re: Very old release, unsupported platform
On 07/01/2014 11:50 AM, Ben Laurie wrote: Our soon-to-be-released roadmap has this to say on supported platform: * Currency, i.e. a platform is widely deployed and in current use * Vendor support * Available to the dev team, i.e. the dev team have access to a suitable environment in which to test builds and deal with tickets and issues * Dev team ownership, i.e. at least one person on the team is willing to take some responsibility for a platform I strongly suggest to add 8 bit chars and 32 bit ints as an additional requirement. There is some idea that 16-bit platforms (such as MS-DOS or Windows prior to the Win32 API) are still supported, but this is clearly not the case because a lot of bounds checks assume 32-bit ints. -- Florian Weimer / Red Hat Product Security __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Very old release, unsupported platform
On 2 July 2014 13:33, Florian Weimer fwei...@redhat.com wrote: On 07/01/2014 11:50 AM, Ben Laurie wrote: Our soon-to-be-released roadmap has this to say on supported platform: * Currency, i.e. a platform is widely deployed and in current use * Vendor support * Available to the dev team, i.e. the dev team have access to a suitable environment in which to test builds and deal with tickets and issues * Dev team ownership, i.e. at least one person on the team is willing to take some responsibility for a platform I strongly suggest to add 8 bit chars and 32 bit ints as an additional requirement. There is some idea that 16-bit platforms (such as MS-DOS or Windows prior to the Win32 API) are still supported, but this is clearly not the case because a lot of bounds checks assume 32-bit ints. Are there any of these platforms that would pass the Currency/Vendor support criteria? If so which ones? Thanks Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Very old release, unsupported platform
On 07/02/2014 02:44 PM, Matt Caswell wrote: I strongly suggest to add 8 bit chars and 32 bit ints as an additional requirement. There is some idea that 16-bit platforms (such as MS-DOS or Windows prior to the Win32 API) are still supported, but this is clearly not the case because a lot of bounds checks assume 32-bit ints. Are there any of these platforms that would pass the Currency/Vendor support criteria? If so which ones? I fear that eComStation could fit these criteria, for the platforms I mentioned. -- Florian Weimer / Red Hat Product Security __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Very old release, unsupported platform
Personnally, and although I am not at all a M$ fan, really not at all, I would not consider XP or any win32-like platform since XP as outdated, as, finally, what openssl needs from the platform ? some standard-C lib, bsd-like sockets, and some (a very few) posix services or equivalents. Some things that, for example, even Windows CE 5.0 is providing (and I will again send a quite small patch to have full support of WCE 5/ WM6 in the near future). Since 1995, winsock2 and CRT lib or MT lib are quite stable on win32 platforms: so I would not see any reason to support, eg, w8 and not XP. Openssl is not even (certified as) MT-safe...while it could be (with some code adaptation), even on win32 platforms (that offer more or less all the minimum services for that, as in unices/linuxes). And when I see the very big list of supported platforms with vms or obscure unices flavors, I would not understand that win32 platforms since XP be claimed as outdated or unsupported. I would add that, of course, openssl is even more needed on platforms that are lacking security support by their own manufacturers. But it is not because a platform is not officially supported by M$ or any other manufacturer, that it is outdated (I mean : unused in the real world), it is (or should be) just the contrary : it is because something is never used any more anywhere that it can be considered as outdated...and then may not need anymore support... I would add that, in very particular cases, some platform that are rarely used, may still be supported by openssl team, or at least community, just for the memory of the project and the maintaining of some skills...and the consistency of the code : going to un-support some platform SHOULD lead to REMOVE some code : this can dangeroulsy have many side effects... I appreciate that Rich Salz is deeply diving into old RT patches or bug reports, and we have all to help in that sense: but removing bug reports from the RT-list is one thing, removing any #ifdef in the code and/or official support for some platform is another thing that I would not recommend before old RT-reports ( 5 years) have been cleared/clarified by Rich and others. I would add a probably very stupid question : as I mentioned earlier, openssl is just using very common services from the platform (compilation platform + runtime platform), that are very common on many platforms for years, so that I do not clearly understand why openssl team supports so many versions of openssl : 0.9.8 1.0.0 1.0.1 1.0.2 1.1.x ...a to z...(fips is something else I know that...) Is there any runtime platform that can run 0.9.8 without being able to run 1.0.2 ?...strange to me. For me this sounds more dispersive than platform support. What I mean is that I would better understand devteam to push people to use only the latest or last two versions of openssl, rather than pushing some platform out of support, out of the code... ...unless...openssl team receives funds to maintain such 0.9.x versions by some customers, something that I can understand. Regards Pierre Le 01/07/2014 07:52, Zoltan Arpadffy a écrit : Hi, I see that Rich is doing a fantastic job by cleaning up the backlog... I absolutely agree that very old releases cannot be supported, but what about the platforms? I thought until now, that as long there are developers who are willing to develop for a certain platform and there is some community interest in using that - the platform will be supported as odd might it be in the Windows and Linux dominated World. I just started to wonder, will soon come the time when my patches will be also refused with the unsupported platform comment? Thank you. Regards, Z -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Rich Salz via RT Sent: den 30 juni 2014 23:43 To: pwal...@au1.ibm.com Cc: openssl-dev@openssl.org Subject: [openssl.org #1610] OS400 patches Very old release, unsupported platform. Closing ticket. G'day, mate. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Very old release, unsupported platform
On 1 July 2014 06:52, Zoltan Arpadffy z...@polarhome.com wrote: Hi, I see that Rich is doing a fantastic job by cleaning up the backlog... I absolutely agree that very old releases cannot be supported, but what about the platforms? I thought until now, that as long there are developers who are willing to develop for a certain platform and there is some community interest in using that - the platform will be supported as odd might it be in the Windows and Linux dominated World. I just started to wonder, will soon come the time when my patches will be also refused with the unsupported platform comment? Our soon-to-be-released roadmap has this to say on supported platform: * Currency, i.e. a platform is widely deployed and in current use * Vendor support * Available to the dev team, i.e. the dev team have access to a suitable environment in which to test builds and deal with tickets and issues * Dev team ownership, i.e. at least one person on the team is willing to take some responsibility for a platform __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Very old release, unsupported platform
On 1 July 2014 10:50, Ben Laurie b...@links.org wrote: On 1 July 2014 06:52, Zoltan Arpadffy z...@polarhome.com wrote: Hi, I see that Rich is doing a fantastic job by cleaning up the backlog... I absolutely agree that very old releases cannot be supported, but what about the platforms? I thought until now, that as long there are developers who are willing to develop for a certain platform and there is some community interest in using that - the platform will be supported as odd might it be in the Windows and Linux dominated World. I just started to wonder, will soon come the time when my patches will be also refused with the unsupported platform comment? Our soon-to-be-released roadmap has this to say on supported platform: * Currency, i.e. a platform is widely deployed and in current use * Vendor support * Available to the dev team, i.e. the dev team have access to a suitable environment in which to test builds and deal with tickets and issues * Dev team ownership, i.e. at least one person on the team is willing to take some responsibility for a platform The roadmap has now been announced on the -users list: http://marc.info/?l=openssl-usersm=140421380818174w=2 It is available here: https://www.openssl.org/about/roadmap.html Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Very old release, unsupported platform
Hi, With the second criteria Vendor Support, M$ will dictate easily the openssl roadmap (?!?!?), and, indirectly, will force any openssl win-XX users to migrate to their last wonderful products. Clearly, above common sense, Vendor support is not a proper criteria to offer something like openssl or anything else to a platform. Criteria such as platform still in use is more appropriate. And I do not think either that devteam wish or present skills, should be also the limit of openssl availability/compatibility/support on some platforms : If the devteam miss some skills, they can -at least- call the community. I think that, through some diving in the forum posts history, it is quite easy to identify some skilled people... I am still, regularly, offering wce support, for free, and I am glad if this can help the team and the community. Isn't it, finally, one of the purpose of community projects : bringing skills together for better products... Regards Pierre Le 01/07/2014 11:50, Ben Laurie a écrit : On 1 July 2014 06:52, Zoltan Arpadffy z...@polarhome.com wrote: Hi, I see that Rich is doing a fantastic job by cleaning up the backlog... I absolutely agree that very old releases cannot be supported, but what about the platforms? I thought until now, that as long there are developers who are willing to develop for a certain platform and there is some community interest in using that - the platform will be supported as odd might it be in the Windows and Linux dominated World. I just started to wonder, will soon come the time when my patches will be also refused with the unsupported platform comment? Our soon-to-be-released roadmap has this to say on supported platform: * Currency, i.e. a platform is widely deployed and in current use * Vendor support * Available to the dev team, i.e. the dev team have access to a suitable environment in which to test builds and deal with tickets and issues * Dev team ownership, i.e. at least one person on the team is willing to take some responsibility for a platform __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Very old release, unsupported platform
On Tue, Jul 01, 2014 at 12:37:31PM +0100, Matt Caswell wrote: I just started to wonder, will soon come the time when my patches will be also refused with the unsupported platform comment? Our soon-to-be-released roadmap has this to say on supported platform: * Currency, i.e. a platform is widely deployed and in current use * Vendor support * Available to the dev team, i.e. the dev team have access to a suitable environment in which to test builds and deal with tickets and issues * Dev team ownership, i.e. at least one person on the team is willing to take some responsibility for a platform The roadmap has now been announced on the -users list: Of note from the roadmap: * Non-supported platforms requiring regular maintenance activities will eventually be removed from the code after first seeking community owners to support the platforms in platform specific repositories. For the record, I'm absolutely in favor of the platform support strategy documented in the roadmap. I would assume that something that follows from the above that patches for these non-supported platforms will be applied only if they don't impose maintenance costs, and that it will be up to community owners interested in supporting these patches to make the support as painless as possible. For example, I'll accept patches for e2fsprogs for non-supported platforms (I don't have a FreeBSD platform at hand), but if the patch doesn't apply, or if it causes regression test failures, I will in general not try to fix up the patch; I'll bounce it back to the patch submitter who is much more well suited to create a proper patch that applies against the tip of the development patch and doesn't cause any problems. Well, sometimes I'll be nice and do some minimal cleanups, but I don't feel *obliged* to do anything more than this. If this is how the OpenSSL team plans to run things, it might be useful to put a statement similar to the above into their to-be-published Document Strategy docuement. - Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Very old release, unsupported platform
On 1 July 2014 13:37, Pierre DELAAGE delaage.pie...@free.fr wrote: Hi, With the second criteria Vendor Support, M$ will dictate easily the openssl roadmap (?!?!?), and, indirectly, will force any openssl win-XX users to migrate to their last wonderful products. Clearly, above common sense, Vendor support is not a proper criteria to offer something like openssl or anything else to a platform. Criteria such as platform still in use is more appropriate. This is, in fact, the first criterium listed, phrased as Currency, i.e. a platform is widely deployed and in current use. And I do not think either that devteam wish or present skills, should be also the limit of openssl availability/compatibility/support on some platforms : If the devteam miss some skills, they can -at least- call the community. I think that, through some diving in the forum posts history, it is quite easy to identify some skilled people... I am still, regularly, offering wce support, for free, and I am glad if this can help the team and the community. Isn't it, finally, one of the purpose of community projects : bringing skills together for better products... Regards Pierre Le 01/07/2014 11:50, Ben Laurie a écrit : On 1 July 2014 06:52, Zoltan Arpadffy z...@polarhome.com wrote: Hi, I see that Rich is doing a fantastic job by cleaning up the backlog... I absolutely agree that very old releases cannot be supported, but what about the platforms? I thought until now, that as long there are developers who are willing to develop for a certain platform and there is some community interest in using that - the platform will be supported as odd might it be in the Windows and Linux dominated World. I just started to wonder, will soon come the time when my patches will be also refused with the unsupported platform comment? Our soon-to-be-released roadmap has this to say on supported platform: * Currency, i.e. a platform is widely deployed and in current use * Vendor support * Available to the dev team, i.e. the dev team have access to a suitable environment in which to test builds and deal with tickets and issues * Dev team ownership, i.e. at least one person on the team is willing to take some responsibility for a platform __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Very old release, unsupported platform
Ok, sounds that some logical operator is missing between criteria : I understood AND while you suggest it is OR ELSE Hope you are right...but not sure.. Pierre Le 01/07/2014 15:42, Felix Laurie von Massenbach a écrit : On 1 July 2014 13:37, Pierre DELAAGE delaage.pie...@free.fr wrote: Hi, With the second criteria Vendor Support, M$ will dictate easily the openssl roadmap (?!?!?), and, indirectly, will force any openssl win-XX users to migrate to their last wonderful products. Clearly, above common sense, Vendor support is not a proper criteria to offer something like openssl or anything else to a platform. Criteria such as platform still in use is more appropriate. This is, in fact, the first criterium listed, phrased as Currency, i.e. a platform is widely deployed and in current use. And I do not think either that devteam wish or present skills, should be also the limit of openssl availability/compatibility/support on some platforms : If the devteam miss some skills, they can -at least- call the community. I think that, through some diving in the forum posts history, it is quite easy to identify some skilled people... I am still, regularly, offering wce support, for free, and I am glad if this can help the team and the community. Isn't it, finally, one of the purpose of community projects : bringing skills together for better products... Regards Pierre Le 01/07/2014 11:50, Ben Laurie a écrit : On 1 July 2014 06:52, Zoltan Arpadffy z...@polarhome.com wrote: Hi, I see that Rich is doing a fantastic job by cleaning up the backlog... I absolutely agree that very old releases cannot be supported, but what about the platforms? I thought until now, that as long there are developers who are willing to develop for a certain platform and there is some community interest in using that - the platform will be supported as odd might it be in the Windows and Linux dominated World. I just started to wonder, will soon come the time when my patches will be also refused with the unsupported platform comment? Our soon-to-be-released roadmap has this to say on supported platform: * Currency, i.e. a platform is widely deployed and in current use * Vendor support * Available to the dev team, i.e. the dev team have access to a suitable environment in which to test builds and deal with tickets and issues * Dev team ownership, i.e. at least one person on the team is willing to take some responsibility for a platform __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: Very old release, unsupported platform
I thought until now, that as long there are developers who are willing to develop for a certain platform and there is some community interest in using that - the platform will be supported as odd might it be in the Windows and Linux dominated World. With the releases now in github, one possibility is to create a fork and maintain odd platform support separately. This was not possible before. I just started to wonder, will soon come the time when my patches will be also refused with the unsupported platform comment? It's possible. We're working on policy and defining our terms. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
RE: Very old release, unsupported platform
Hope you are right...but not sure.. Neither are we. That is why the current roadmap says that we're working on it. It's important to realize that supporting a platform incurs a cost, and we need to have some way of making the appropriate trade-offs. Clearly, we don't want to end up where our libre colleagues are starting from, but the previous approach that we'll take any platform or toolchain patches has contributed to complexity and poor code quality. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
Re: Very old release, unsupported platform
Of course supporting a platform is incurring some costs, ...that can be shared with the community: this is one of its purpose. I would like to point out that for some platform, devteam could propose a limited support/usability statement : Typically, for WCE on which I am regularly working : The devteam, after integrating some patch, JUST CHECKING that it compiles, seems logical, and has NO SIDE EFFECT on other platforms, could state, COMPILE, (known to) RUN for this and this scenario (to be defined) and/or on this and this devices/configs (as indicated by patch submitter), BUT IS NOT GUARANTEED TO PASS SUCCESSFULLY the OFFICIAL OPENSSL TEST-SUITE. This is very common : you could offer wide compatibility but LIMIT your SUPPORT (by devteam) to some very few widely used platforms, BUT letting a way for the community to continue to bring support for some low interest platforms. Forking is never a good idea : I have many times taken snapshots of official openssl to resolve some wce compilation bugs, and of course I do NOT want to re-invent the openssl wheel, and re-importing many times my wce fixes in openssl snapshots was really a pain. In the WCE particular case, I do my best to keep a full compatibility between my code and the Desktop W32 main code, avoiding as much as possible new #ifdef. For example, on the 1.1.x snapshot of the 20140624 I am working on, there is a very little amount of fixes for WCE : and most of them are just fully compatible with W32 main stream. For platform support in general : I hope that there will be a specific porting guide, relying on isolating platform specific code in specific source files. For example, it is quite easy to get some win32 posix services implementation, that almost completely avoid the use of #ifdef _WIN32 inside the openssl code : just limiting #ifdef to some #include statements, that can be even isolated in big pool include files. For posix thread, you could use : http://www.sourceware.org/pthreads-win32/ For a general discussion on posix in win32, see also this M$ doc online : http://msdn.microsoft.com/fr-fr/library/y23kc048.aspx Porting from UNIX to Win32 Well these are just examples. This is how I port stunnel to WCE these days : trying to limit #ifdef in the code, and giving equivalent WCE services to w32 original code... WCEcompat is also a very good example of porting without having to put #ifdef everywhere... Then, that way, it is easier for the devteam to be TOLERANT to some ports, while at the same time legitimately claiming NOT GUARANTED on that platform: because porting would be just a matter of replacing some standard module by a specific-port one, something that would just require some Makefile adaptation (already done for WCE...). Yours sincerely Pierre Le 01/07/2014 16:34, Salz, Rich a écrit : Hope you are right...but not sure.. Neither are we. That is why the current roadmap says that we're working on it. It's important to realize that supporting a platform incurs a cost, and we need to have some way of making the appropriate trade-offs. Clearly, we don't want to end up where our libre colleagues are starting from, but the previous approach that we'll take any platform or toolchain patches has contributed to complexity and poor code quality. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz :��IϮ��r�m (���Z+�7�zZ)���1���x ��h���W^��^��%�� __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Very old release, unsupported platform
Hi, I see that Rich is doing a fantastic job by cleaning up the backlog... I absolutely agree that very old releases cannot be supported, but what about the platforms? I thought until now, that as long there are developers who are willing to develop for a certain platform and there is some community interest in using that - the platform will be supported as odd might it be in the Windows and Linux dominated World. I just started to wonder, will soon come the time when my patches will be also refused with the unsupported platform comment? Thank you. Regards, Z -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Rich Salz via RT Sent: den 30 juni 2014 23:43 To: pwal...@au1.ibm.com Cc: openssl-dev@openssl.org Subject: [openssl.org #1610] OS400 patches Very old release, unsupported platform. Closing ticket. G'day, mate. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
