# Intention to move mcrypt to PECL - Thread: https://externals.io/message/96233 - Original archive: https://news-web.php.net/php.internals/96233 - Started by Leigh on 2016-10-04T16:58:11+00:00 - Messages: 22 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #96233 — Leigh — 2016-10-04T16:58:11+00:00 URL: https://externals.io/message/96233#96233 Hello list, It is my intention to create a new PECL package for ext/mcrypt, so that it can be removed from master as per the RFC (https://wiki.php.net/rfc/mcrypt-viking-funeral) I do not expect there to be any updates to the extension after it has been migrated, however we voted to move it there. Any objections/comments? If not I'll apply for my PECL account in the next few days. Cheers, Leigh. --- ## #96258 — Derick Rethans — 2016-10-05T19:11:28+00:00 URL: https://externals.io/message/96233#96258 · In reply to: #96233 > Hello list, > > It is my intention to create a new PECL package for ext/mcrypt, so > that it can be removed from master as per the RFC > (https://wiki.php.net/rfc/mcrypt-viking-funeral) > > I do not expect there to be any updates to the extension after it has > been migrated, however we voted to move it there. > > Any objections/comments? If not I'll apply for my PECL account in the > next few days. It should be migrated properly, and also to GIT. I prefer that it is released with my username as "lead", as I wrote a big deal of it. cheers, Derick --- ## #96259 — Pierre Joye — 2016-10-06T03:11:03+00:00 URL: https://externals.io/message/96233#96259 · In reply to: #96233 hi Leigh, > Hello list, > > It is my intention to create a new PECL package for ext/mcrypt, so > that it can be removed from master as per the RFC > (https://wiki.php.net/rfc/mcrypt-viking-funeral) > > I do not expect there to be any updates to the extension after it has > been migrated, however we voted to move it there. > > Any objections/comments? If not I'll apply for my PECL account in the > next few days. I am not sure to follow. We rejected to move it out of the core for 7.0. This RFC is about deprecation for 7.1. As much as I want to kill this beast as soon as possible, I do not think we can kill it in 7.x but 8.x. It is also why I was pushing so hard to kill it in 7.0, knowing that this will be tried again and sadly for 7.x. Cheers, Pierre --- ## #96260 — Davey Shafik — 2016-10-06T03:22:15+00:00 URL: https://externals.io/message/96233#96260 · In reply to: #96259 > hi Leigh, > > > > […] > > I am not sure to follow. > > We rejected to move it out of the core for 7.0. This RFC is about > deprecation for 7.1. > > As much as I want to kill this beast as soon as possible, I do not > think we can kill it in 7.x but 8.x. It is also why I was pushing so > hard to kill it in 7.0, knowing that this will be tried again and > sadly for 7.x. From the RFC: > In PHP 7.1+1 (be it 7.2 or 8.0), the crypt extension will be moved out of core and into PECL and > Vote “Yes” to raise an `E_DEPRECATED` notice in PHP 7.1 when any crypt function is used and to remove the extension from core in 7.1+1. So, per the RFC, moving to PECL in 7.2 is correct. - Davey --- ## #96261 — Pierre Joye — 2016-10-06T05:02:06+00:00 URL: https://externals.io/message/96233#96261 · In reply to: #96260 > > > […] > > > From the RFC: > > > […] > > and > > > […] > > So, per the RFC, moving to PECL in 7.2 is correct. "In PHP 7.1+1 (be it 7.2 or 8.0)," I took it as 8, for the reason explained earlier. -- Pierre @pierrejoye | http://www.libgd.org --- ## #96262 — Nikita Popov — 2016-10-06T08:41:49+00:00 URL: https://externals.io/message/96233#96262 · In reply to: #96260 > > > > […] > > > From the RFC: > > > […] > core and into PECL > > and > > > […] > function is used and to remove the extension from core in 7.1+1. > > So, per the RFC, moving to PECL in 7.2 is correct. > > - Davey > Furthermore the release process RFC *explicitly* allows moving extensions to PECL in minor versions. Nikita --- ## #96263 — Leigh — 2016-10-06T08:44:47+00:00 URL: https://externals.io/message/96233#96263 · In reply to: #96258 > It should be migrated properly, and also to GIT. I prefer that it is > released with my username as "lead", as I wrote a big deal of it. > > cheers, > Derick I'm not sure what you mean by "properly", what steps do you think I'll miss out? (My intention was always to ask for a php.net git repo for it) Of course you (and Sascha) should be listed as lead (I'll leave the "active" flags up to you - not sure if this is supposed to mean in general, or on the extension itself), I have little interest in maintaining this extension myself. My motivation is to remove it from master as soon as possible, so those testing or experimenting with future releases get an early indication of what is coming, rather than it happening at 7.2 beta and people only getting a couple of months. However the RFC said remove and move to PECL, so I am trying to follow what we agreed on, and get it moved to PECL prior to deleting it from master. Would you like to handle this migration yourself? --- ## #96264 — Pierre Joye — 2016-10-06T08:45:26+00:00 URL: https://externals.io/message/96233#96264 · In reply to: #96262 > > > > […] of > > […] > > > Furthermore the release process RFC *explicitly* allows moving extensions to PECL in minor versions. I am *not* (I can emphasize text too ;) it is not allowed. What I am saying is why we refused to do it in 7.0 and then the same go all in for 7.2. That makes no sense to me and it is something we should figure out for 8 (exts or behaviors). --- ## #96265 — Remi Collet — 2016-10-06T09:09:51+00:00 URL: https://externals.io/message/96233#96265 · In reply to: #96264 Le 06/10/2016 à 10:45, Pierre Joye a écrit : > > > […] > of > > […] > to PECL in minor versions. > > I am *not* (I can emphasize text too ;) it is not allowed. > > What I am saying is why we refused to do it in 7.0 and then the same go all > in for 7.2. That makes no sense to me and it is something we should figure > out for 8 (exts or behaviors). > Checking the https://wiki.php.net/rfc/releaseprocess x.y.z to x.y+1.z (so 7.2) * Extensions support can be ended (moved to pecl) This will not be a major issue, as most people will be able to find this extension in the various binary distribution. This is important to give information about this extension being unsupported, as relying on a dead project. Remi. --- ## #96266 — Jakub Zelenka — 2016-10-06T10:12:37+00:00 URL: https://externals.io/message/96233#96266 · In reply to: #96233 Hi, > Hello list, > > It is my intention to create a new PECL package for ext/mcrypt, so > that it can be removed from master as per the RFC > (https://wiki.php.net/rfc/mcrypt-viking-funeral) > > I do not expect there to be any updates to the extension after it has > been migrated, however we voted to move it there. > > Any objections/comments? If not I'll apply for my PECL account in the > next few days. > > I don't think it can be added to PECL as it breaks its licensing rules (mcrypt is GPL licensed): - Note: wrappers for GPL (all versions) or LGPLv3 libraries will not be accepted. Wrappers for libraries licensed under LGPLv2 are however allowed while being discouraged. See https://pecl.php.net/account-request.php Cheers Jakub --- ## #96267 — Lester Caine — 2016-10-06T10:41:10+00:00 URL: https://externals.io/message/96233#96267 · In reply to: #96266 > I don't think it can be added to PECL as it breaks its licensing rules > (mcrypt is GPL licensed): It is already an established component in PHP and while it's use has been discouraged for a long time, simply switching it off will break a lot of legacy applications. It is not simply a matter of 'changing to a more modern alternative'. If an application has data stored by mcrypt, and it was a popular method of encoding passwords, then any migration path is going to need to provide a method of re-encoding that data while mcrypt is still available. There needs to be a proper migration guide to identify the secondary effects of pulling it although as has been indicated, many distributions will simply build it from PECL and carry on providing it, so the move only really impacts people who build their own installations ... and even there it's a simple exercise to restore anything relegated to the second level of code storage. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #96268 — Leigh — 2016-10-06T12:24:49+00:00 URL: https://externals.io/message/96233#96268 · In reply to: #96266 > Hi, > > > > […] > > I don't think it can be added to PECL as it breaks its licensing rules > (mcrypt is GPL licensed): > > Note: wrappers for GPL (all versions) or LGPLv3 libraries will not be > accepted. Wrappers for libraries licensed under LGPLv2 are however allowed > while being discouraged. > > See https://pecl.php.net/account-request.php > > Cheers > > Jakub > Interesting, thanks for that. --- ## #96269 — Ferenc Kovacs — 2016-10-06T12:35:19+00:00 URL: https://externals.io/message/96233#96269 · In reply to: #96266 > Hi, > > > > > […] > I don't think it can be added to PECL as it breaks its licensing rules > (mcrypt is GPL licensed): > > > - Note: wrappers for GPL (all versions) or LGPLv3 libraries will not be > accepted. Wrappers for libraries licensed under LGPLv2 are however > allowed > while being discouraged. > > See https://pecl.php.net/account-request.php > > Cheers > > Jakub > AFAIK mcrypt is gpl, libmcrypt (wrapped by our mcrypt ext) is lgpl so it would be fine for pecl. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #96270 — Leigh — 2016-10-06T12:38:05+00:00 URL: https://externals.io/message/96233#96270 · In reply to: #96269 > > > > > […] > > > AFAIK mcrypt is gpl, libmcrypt (wrapped by our mcrypt ext) is lgpl so it > would be fine for pecl. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu http://mcrypt.cvs.sourceforge.net/viewvc/mcrypt/libmcrypt/COPYING.LIB?revision=1.1.1.1&view=markup LGPLv2 --- ## #96271 — Jakub Zelenka — 2016-10-06T12:48:48+00:00 URL: https://externals.io/message/96233#96271 · In reply to: #96270 > > > […] > be > > […] > > http://mcrypt.cvs.sourceforge.net/viewvc/mcrypt/libmcrypt/ > COPYING.LIB?revision=1.1.1.1&view=markup > > LGPLv2 > Looks like copying says LGPLv2 but the files seems to be under GPLv2. See for example http://mcrypt.cvs.sourceforge.net/viewvc/mcrypt/libmcrypt/lib/mcrypt.h.in?view=markup That's why I thought it's GPL. Not sure what's more important though... Cheers Jakub --- ## #96273 — Dan Ackroyd — 2016-10-06T13:46:14+00:00 URL: https://externals.io/message/96233#96273 · In reply to: #96271 > > > Looks like copying says LGPLv2 but the files seems to be under GPLv2. See > for example > > http://mcrypt.cvs.sourceforge.net/viewvc/mcrypt/libmcrypt/lib/mcrypt.h.in?view=markup Er, unless i'm missing what you mean that file says "Library General Public License" aka LGPL. cheers Dan --- ## #96274 — Jakub Zelenka — 2016-10-06T14:11:30+00:00 URL: https://externals.io/message/96233#96274 · In reply to: #96273 > > > > […] > lib/mcrypt.h.in?view=markup > > Er, unless i'm missing what you mean that file says "Library General > Public License" aka LGPL. > > Ah. I'm such an idiot. :) Sorry! Ignore me. Should be fine then. --- ## #96497 — Leigh — 2016-10-19T17:44:33+00:00 URL: https://externals.io/message/96233#96497 · In reply to: #96258 > It should be migrated properly, and also to GIT. > Hi Ferenc, Can you create a php.net hosted git repository for this (I guess under the pecl/security namespace), and grant karma to leigh@php.net for it. Sorry for picking on you personally. I don't know who else can do this :) Cheers, Leigh. --- ## #96543 — Daniel Morris — 2016-10-21T20:14:06+00:00 URL: https://externals.io/message/96233#96543 · In reply to: #96267 > It is already an established component in PHP and while it's use has > been discouraged for a long time, simply switching it off will break a > lot of legacy applications. How many applications that are not following standard security guidelines are not following basic security principles? It doesn't matter if it's an established component, a vulnerability is a vulnerability. BC shouldn't matter; especially for those who are not willing to patch their applications to use the latest information we have available to us. You either keep up with changes; or you don't. New majors, and even minors (if we're ignoring semantic versioning) should be able to change something, it should be up to the maintainers of an application to decide whether it's time to upgrade or not, internals shouldn't manage that for you. If you're using Composer, you can lock your dependencies to prevent your application from breaking. If you're up to date with the latest information, you can choose to evolve. Mcrypt, now (I think) belongs in PECL, I will be looking at (a major) code repository over the next few weeks and looking to provide a simple upgrade path. DM --- ## #97362 — Ferenc Kovacs — 2016-12-12T00:52:58+00:00 URL: https://externals.io/message/96233#97362 · In reply to: #96497 > > > > > […] > > Hi Ferenc, > > Can you create a php.net hosted git repository for this (I guess under > the pecl/security namespace), and grant karma to leigh@php.net for it. > > Sorry for picking on you personally. I don't know who else can do this :) > > Cheers, > > Leigh. > > > Hi, I've just created the http://git.php.net/?p=pecl/encryption/mcrypt.git repository (I think encryption was a better category as we already have scrypt, libsodium and mcrypt_filter there). Leigh already had karma for pecl/*, let me know if you need help with creating the package or importing the source to the repo ( https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/ if you want to keep the history). -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #97368 — Leigh — 2016-12-12T15:18:35+00:00 URL: https://externals.io/message/96233#97368 · In reply to: #97362 Ok rookie PECL mistake here. I was adding Derick and Sascha as leads (as they were the original leads) and demoting myself to helper (not knowing it was required to further maintain the package). So I have locked myself out :) Could you add me back as a lead to the pecl package please, so I can upload the release tarball. Cheers, Leigh > > > > > > > It should be migrated properly, and also to GIT. > > > Hi Ferenc, > > Can you create a php.net hosted git repository for this (I guess under > the pecl/security namespace), and grant karma to leigh@php.net for it. > > Sorry for picking on you personally. I don't know who else can do this :) > > Cheers, > > Leigh. > > > > > Hi, > > I've just created the http://git.php.net/?p=pecl/encryption/mcrypt.git > repository (I think encryption was a better category as we already have > scrypt, libsodium and mcrypt_filter there). > Leigh already had karma for pecl/*, let me know if you need help with > creating the package or importing the source to the repo ( > https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/ > if you want to keep the history). > > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu --- ## #97373 — Derick Rethans — 2016-12-12T17:18:09+00:00 URL: https://externals.io/message/96233#97373 · In reply to: #97368 > Ok rookie PECL mistake here. > > I was adding Derick and Sascha as leads (as they were the original leads) > and demoting myself to helper (not knowing it was required to further > maintain the package). So I have locked myself out :) > > Could you add me back as a lead to the pecl package please, so I can upload > the release tarball. Done :-) Make sure you keep it in the package.xml too, otherwise it gets reset again. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php twitter: @derickr and @xdebug