From helmut.hummel at typo3.org Sun Feb 5 16:27:18 2012 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Sun, 05 Feb 2012 16:27:18 +0100 Subject: [TYPO3-ect] Ideas to clean up TER In-Reply-To: References: Message-ID: Hi, On 30.01.12 20:50, Xavier Perseguers wrote: > Exactly! We have enough to do, let's keep this cleanup stupid and > simple, I really don't see the problem of asking authors (or someone > else taking over the ownership) to submit a new version of > outdated-yet-still-must-be-used extensions to comply with these new rules. I think that there's a consensus in getting outdated extensions out of the normal search in the EM and even normal TER search on the website. So what are the next steps here? Who needs to be involved to get a final decision? Kind regards, Helmut -- Helmut Hummel TYPO3 Security Team Leader, TYPO3 v4 Core Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From oliver.hader at typo3.org Mon Feb 13 07:17:09 2012 From: oliver.hader at typo3.org (Oliver Hader) Date: Mon, 13 Feb 2012 07:17:09 +0100 Subject: [TYPO3-ect] Ideas to clean up TER In-Reply-To: References: Message-ID: Hi everybody, thanks for your ideas and feedback on this topic. I share the thoughts of "hiding" outdated extensions in the extension manager and the TER online search at the same time. However it might make sense to have an additional search for those with a big red warning which states that these extensions are not maintained by the original author and the security team anymore. What we need to continue: 1) News article to announce the whole procedure with a detailed explanation of why this happens, what the consequences will be and how to circumvent a extension gets "invalid" 2) Write to extension authors directly (use the email address in ext_emconf.php) and/or the mail address of the key owner - this way we can check if these addresses are still valid 3) modify the ter_fe extension to support outdated extensions - there's something going on for the typo3.org relaunch - however I could not find the accordant project on forge.typo3.org - might be that one: http://forge.typo3.org/projects/show/extension-terfe (ter_fe2 branch) 4) "connector" to current TYPO3 version needs to be integrated (to find out automatically when a version is considered as outdated) From bogus@does.not.exist.com Sat Feb 4 17:32:46 2012 From: bogus@does.not.exist.com () Date: Sat, 04 Feb 2012 16:32:46 -0000 Subject: No subject Message-ID: responsible for this initiative. However, then the ECT needs some more new and active members - see the project page on Forge: http://forge.typo3.org/projects/show/team-ect So, first step would be to create a detailed first version to describe the procedure and the rules. Cheers, Olly Am 29.01.12 07:26, schrieb Jigal van Hemert: > Hi, > > From a small Twitter conversation with Xavier Perseguers and Helmut > Hummel the idea was born to clean up TER a bit and remove *) old > extensions. > Of course the registration and status will not be removed to make sure > they show up as the Extension Manager as removed/unsupported. > > Proposals: > > 1. the version constraints in em_conf.php will become mandatory (and > cannot be higher than the current development version (a.k.a. "master")) > > 2. once a TYPO3 core version becomes end of life the extensions which > have that version as the upper limit will be removed from TER > > 3. there will be a grace period for extension authors to update their > extensions. Extension authors will be notified (on the address > registered in typo3.org) of this change. This change will be published > in the relevant places (newsgroups/mailing lists, typo3.org) > > 4. the procedure to transfer extensions will be slightly adapted for > extensions which were removed because of "old age". > > > Questions: > > - do we need a new 'status' to reflect the fact that an extension is > removed because it's considered old (instead of insecure)? > - should authors be notified before a core version becomes EOL that > their extension will be removed? > > What do you think? > > *) Removed as in: not available for download in TER. -- Oliver Hader TYPO3 v4 Core Team Leader TYPO3 .... inspiring people to share! Get involved: http://typo3.org From typo3ml at schams.net Mon Feb 13 09:08:38 2012 From: typo3ml at schams.net (Michael) Date: Mon, 13 Feb 2012 19:08:38 +1100 Subject: [TYPO3-ect] Ideas to clean up TER In-Reply-To: References: Message-ID: On 13/02/12 17:17, Oliver Hader wrote: > [...] I share the thoughts > of "hiding" outdated extensions in the extension manager and the TER > online search at the same time. However it might make sense to have an > additional search for those with a big red warning which states that > these extensions are not maintained by the original author and the > security team anymore. +1, as suggested in: http://lists.typo3.org/pipermail/typo3-team-extension-coordination/2012-January/003941.html > What we need to continue: > > 1) News article to announce the whole procedure with a detailed > explanation of why this happens, what the consequences will be and how > to circumvent a extension gets "invalid" > 2) Write to extension authors directly (use the email address in > ext_emconf.php) and/or the mail address of the key owner - this way we > can check if these addresses are still valid I assume this applies to *ALL* ext developers: even if their ext already shows a dependency to (valid) "start/stop" TYPO3 versions. Please keep in mind that the email in ext_emconf.php (which is in fact the same as in the TYPO3 database table "cache_extensions") is an arbitrary field. I had a quick look at the DB table and some records are empty, some show more than one email address (comma-separated), some show invalid addresses like "user_NOSPAM at domain.com" or "user(at)domain.com", etc. > 3) modify the ter_fe extension to support outdated extensions - there's > something going on for the typo3.org relaunch - however I could not find > the accordant project on forge.typo3.org - might be that one: > http://forge.typo3.org/projects/show/extension-terfe (ter_fe2 branch) > 4) "connector" to current TYPO3 version needs to be integrated (to find > out automatically when a version is considered as outdated) The identification of "unmaintained" extensions should be on our ToDo list, too. This covers to change the TER to accept new extensions and extension updates only, if they have the "start" and "stop" TYPO3 version set (I assume this is the SOAP interface for t3x upload?). This possibly also requires a change of the EM, to make these two fields mandatory? Or am I wrong? > [...] then the ECT needs some more > new and active members - see the project page on Forge: [...] I would be happy to contribute to this initiative, depending on the tasks and timelines of this. Or, at least support the ECT in their efforts. Cheers Michael From jigal at xs4all.nl Sat Feb 18 12:31:34 2012 From: jigal at xs4all.nl (Jigal van Hemert) Date: Sat, 18 Feb 2012 12:31:34 +0100 Subject: [TYPO3-ect] TER clean up actions Message-ID: TER Cleanup The text below will be put in the ECT wiki too. It outlines the steps we need to take, technical considerations, time frame, etc. Steps 1. Communication 2. Modify TER_fe search 3. Modify EM 4. Add Reports item 5. Periodically mark extensions in TER as outdated 6. Support in third party extensions 1 Communication 1.1 Announcements * news, buzz * mailing lists The TER cleanup will be announced in as many places as possible. The announcement will explain: * which extensions are affected * the impact of existing installations (after core update) * actions which extension authors need to take * actions which site owners can take * consequences for security issues 1.2 Mailing extension authors * extension key owners * authors in ext_emconf.php Extension authors will be notified that their extensions will be marked as outdated after a grace period (6 months?). The notification will also tell what actions an extension author can take to prevent the extension from being marked as 'outdated'. 2 TER fe search 2.1 Exclude outdated extensions from standard search Extensions which are marked as 'outdated' will be excluded from the results of TER search. As the new ter_fe plugin will most likely be used on the typo3.org website when the grace period has ended, these changes need to be included in the new plugin. 2.2 Extra search for outdated extensions An extra search for 'outdated' extensions needs to be created or a search option needs to be added to include 'outdated' extensions in the search results. This will also be included in the new ter_fe extension. 3 Extension Manager 3.1 Status for outdated, installed extensions Extensions which are marked as 'outdated' need to be marked accordingly in the Extension Manager. The UI design team will be asked to make a visual design for this. Patches for all supported branches need to be made. 3.2 Force TYPO3 dependency setting on upload New versions of extensions need to have a dependency on TYPO3 for at least the lowest currently supported branch. When uploading an extension this dependency must be checked and missing or too low dependencies must be rejected. Existing EM version already send dependencies to TER and can handle error messages. This is a change in the TER server, but it requires knowledge in the TER server of the currently supported versions. 3.3 Hide outdated extensions in TER search For this change there are two different situations: * existing installations which are not updated (yet) * new or updated installations To hide outdated extensions in existing installations we could use the field reviewstate. They would then become 'removed as insecure'. See section on technical implications. Installations of supported branches will have an updated EM which hides outdated extensions in search results. 4 Reports module 4.1 Reports module: List outdated extensions Depending on the technical implementation the Reports module will also show which installed extensions are marked as 'outdated'. At the same time we can list extensions which have an upper limit in the TYPO3 dependencies which is lower than the current version (this can happen after a core upgrade). This will help integrators to take appropriate actions during a test upgrade. 5 Periodically mark extensions in TER as outdated 5.1 Periodic task: extensions with max dependency < deprecated Whenever a branch is declared EOL extensions with a upper limit in the dependency settings of this branch will be marked as 'outdated'. This can be implemented as a script which checks the entries in the TER database. Running this script must be added to the procedures for the Release Managers. 5.2 Periodic task: extensions without dependency which are older than x years Because a lot of extensions do not have dependency settings yet the script of the first cleanup can be used periodically to mark old extensions as 'outdated'. 6 Support in third party extensions Once the changes in TER/EM are known and the technical implementation is clear authors of known third party extensions which provide monitoring services will be notified of these technical changes. Extensions which provide such a service are: 1 caretaker 2 nagios 3 ... 7 Technical considerations With the cleanup action and the changes we have to try to maintain as much backwards compatibility as possible. Solutions which hide 'outdated' extensions in unmodified Extension Managers are preferred. 7.1 Using reviewstate setting Currently the EM checks for reviewstate=-1 to detect insecure extensions. The Security Team already mentioned that 'outdated' extensions will not have their focus. In this light we could consider them as being insecure because they are outdated, unsupported and not maintained. Using these extensions will be the sole responsibility of the integrator. 7.2 Difference between 'insecure' and 'outdated' For updated EM versions there should be a difference between 'outdated' and 'insecure' extensions. In the EM only extensions with a review state greater than or equal to zero are shown. Extensions with a review state of less than zero are marked as 'insecure'. In this light the proposal is to use a review state of -2 (minus two) to indicate 'outdated' extensions. 7.3 Dependency check in TER server The TER server needs to be aware of 'current' versions. There are already scripts such as one by Xavier Perseguers [1] which provide version information. A similar script (extended with oldest_supported) could be used by the TER server to check dependencies. The Extension Manager already supports displaying error messages from the TER server, so this only requires changes in the TER server. 8 Next steps 1) check with Security Team, server team, new typo3.org team, Release Managers, UI/design team 2) enter tasks in forge and prioritize them 9 Time schedule * Announcements: a.s.a.p. * Mailing extension authors: a.s.a.p. after getting addresses, etc. * Marking extensions 'outdated': August 1st 2012; which means a grace period of five and a half months to add dependencies and upload a new version * Changes in extensions on TER server and EM: published before July 1st (which means they must be included in core releases before this date) [1] http://typo3.causal.ch/releases.php -- Kind regards / met vriendelijke groet, Jigal van Hemert. From typo3ml at schams.net Sun Feb 19 06:16:06 2012 From: typo3ml at schams.net (Michael) Date: Sun, 19 Feb 2012 16:16:06 +1100 Subject: [TYPO3-ect] TER clean up actions In-Reply-To: References: Message-ID: On 18/02/12 22:31, Jigal van Hemert wrote: > The text below will be put in the ECT wiki too. It outlines the steps we > need to take, technical considerations, time frame, etc. great concept document! :-) > 7.2 Difference between 'insecure' and 'outdated' If we use the "reviewstate" value for classifying 'insecure' (-1) *and* 'outdated' extensions (-2), this would mean, we can not distinguish between both states. It is possible that an extension is "outdated" but not "insecure". It is also possible that an extension is "outdated" and "insecure". Both cases would show "reviewstate = -2" (outdated). Assuming the Security Team would identify a security issue in an extension, which is not outdated yet, reviewstate would be -1. Some months later, the extension becomes outdated and a script would overwrite this state by the value "-2". From this time on, it is not possible to say, if the extension has ever been classified as insecure or not, which is (from my perspective) an important factor for an integrator to make a decision to use (or continue using) the extension or not. Under certain circumstances it could be legitimate to use an outdated/unmaintained extension - but an insecure extension is a no-go! What I mean is: we would loose an important information. Here is a suggestion to address this issue: how about using the binary system as the "reviewstate" value? This makes the logic a little bit more complicated but gives much more flexibility. -1 = insecure -2 = outdated -4 = another classification 1 -8 = another classification 2 -16 = another classification 3 etc. reviewstate = If reviewstate = -1, extension is "insecure" (and insecure only). If reviewstate = -2, extension is "outdated" (and outdated only). If reviewstate = -3, extension is "insecure" and "outdated" (-1 + -2 = -3) If reviewstate = -10, extension is "outdated" and "another classification 2" (-2 + -8 = -10) and so on. This would allow us to extend the "state" of extensions in the future (in theory without limits) and this would also allow the Security Team to exclude extensions with negative reviewstate values. Cheers Michael From jigal at xs4all.nl Sun Feb 19 09:21:08 2012 From: jigal at xs4all.nl (Jigal van Hemert) Date: Sun, 19 Feb 2012 09:21:08 +0100 Subject: [TYPO3-ect] TER clean up actions In-Reply-To: References: Message-ID: Hi Michael, On 19-2-2012 6:16, Michael wrote: >> 7.2 Difference between 'insecure' and 'outdated' > > If we use the "reviewstate" value for classifying 'insecure' (-1) *and* > 'outdated' extensions (-2), this would mean, we can not distinguish > between both states. The Security Team has already mentioned that they wouldn't focus on 'outdated' extensions any more. In the TER database all versions of an extension have their own record. The Security Team only marks versions of extensions as 'insecure' which have the security problem. Both the online TER search and the Extension Manager filter 'insecure' records first and show the latest version of the extensions which still have one or more records left. Both 'insecure' and 'outdated' extensions will not be listed in the TER search in the Extension Manager. You will have to take some effort to get 'outdated' extensions from the online TER (and it will show a warning in that case). 'insecure' extensions can only become listed again when a new (fixed) version is uploaded. This version is then automatically checked for the right TYPO3 version dependency and will then also not be 'outdated' any more. There is also a reviewstate +1 (reviewed by the Security Team), but this is the case only for very few extensions. Because new versions of those extensions have to be re-reviewed before they get this status again we can assume that once they become 'outdated' that they also lose the 'reviewed' status. The 'insecure' state is more severe than the 'outdated' state. I would suggest that we would only mark extensions as 'outdated' if they do not have a 'insecure' state. Anyway, marking extensions as 'outdated' won't be a very trivial query: - to mark an extension without dependencies on TYPO3 as 'outdated' all versions of that extension must be marked - only not-insecure versions can be marked 'outdated' - versions of extensions with dependencies on TYPO3 must be checked individually - TYPO3 4.5 LTS makes dependency checks non-trivial. If you look at the roadmap [1] you'll see that 4.7 will be EOL before 4.5; an extension (version) with dependency 'typo3' => '4.6.0-4.7.99' will be 'outdated' before the previous version 'typo3' => '4.5.0-4.5.99' will be 'outdated'. (This seems illogical at first) We could use a bit-array for the negative values, but it wouldn't add too much at the moment. Maybe to be forward compatible? [1] http://preview.typo3.org/roadmap/ -- Kind regards / met vriendelijke groet, Jigal van Hemert. From franz at ttproducts.de Sun Feb 19 10:08:14 2012 From: franz at ttproducts.de (Franz Holzinger) Date: Sun, 19 Feb 2012 10:08:14 +0100 Subject: [TYPO3-ect] TER clean up actions In-Reply-To: References: Message-ID: Hello Jigal, On 18/02/12 12:31, Jigal van Hemert wrote: > 5 Periodically mark extensions in TER as outdated > > 5.1 Periodic task: extensions with max dependency < deprecated > > Whenever a branch is declared EOL extensions with a upper limit in the > dependency settings of this branch will be marked as 'outdated'. This > can be implemented as a script which checks the entries in the TER > database. Running this script must be added to the procedures for the > Release Managers. > > 5.2 Periodic task: extensions without dependency which are older than x > years > > Because a lot of extensions do not have dependency settings yet the > script of the first cleanup can be used periodically to mark old > extensions as 'outdated'. not whole extensions should be marked as outdated but all old versions of these extensions. If a newer version of an extension is uploaded into TER then the older versions of it should still remain outdated. Also all extension versions in experimental state should be marked as outdated. - Franz From jigal at xs4all.nl Sun Feb 19 10:57:17 2012 From: jigal at xs4all.nl (Jigal van Hemert) Date: Sun, 19 Feb 2012 10:57:17 +0100 Subject: [TYPO3-ect] TER clean up actions In-Reply-To: References: Message-ID: Hi Franz, On 19-2-2012 10:08, Franz Holzinger wrote: > not whole extensions should be marked as outdated but all old versions > of these extensions. If a newer version of an extension is uploaded into > TER then the older versions of it should still remain outdated. > > Also all extension versions in experimental state should be marked as > outdated. Valid points! I've already put the steps I could think of in forge. There is one "umbrella" issue [1] which is the parent of the necessary subtasks (easier to see if everything has been done). Can you add the details to the issue (#34072 I think) ? [1] http://forge.typo3.org/issues/34063 -- Kind regards / met vriendelijke groet, Jigal van Hemert. From typo3ml at schams.net Sun Feb 19 11:00:39 2012 From: typo3ml at schams.net (Michael) Date: Sun, 19 Feb 2012 21:00:39 +1100 Subject: [TYPO3-ect] TER clean up actions In-Reply-To: References: Message-ID: On 19/02/12 20:08, Franz Holzinger wrote: [...] >> Because a lot of extensions do not have dependency settings yet the >> script of the first cleanup can be used periodically to mark old >> extensions as 'outdated'. > > not whole extensions should be marked as outdated but all old versions > of these extensions. I assume, Jigal meant *versions* of extensions. "In the TER database all versions of an extension have their own record." (quoting Jigal) Same in extensions.xml and in database table "cache_extensions". Should we use the terminology "extension record" in the future (which is in fact a version of an extension)? > Also all extension versions in experimental state should be marked as > outdated. Good point! What's about extensions in "test" and "obsolete" state? I can't think about a situation where these extensions should come up in the TER search or in the EM. However, from a logical perspective, test and experimental extensions are not "outdated" automatically (that would be a wrong definition). So, I would not suggest that the intended script marks them as outdated, but we could consider to exclude these states from the TER search and EM by default, when someone is working on the changes anyway. What do you think? The current list of valid states is: alpha, beta, stable, experimental, test and obsolete. Cheers Michael From typo3ml at schams.net Sun Feb 19 11:09:33 2012 From: typo3ml at schams.net (Michael) Date: Sun, 19 Feb 2012 21:09:33 +1100 Subject: [TYPO3-ect] TER clean up actions In-Reply-To: References: Message-ID: On 19/02/12 19:21, Jigal van Hemert wrote: [...] > The 'insecure' state is more severe than the 'outdated' state. I would > suggest that we would only mark extensions as 'outdated' if they do not > have a 'insecure' state. Ok, either this or the bit-array. [...] > We could use a bit-array for the negative values, but it wouldn't add > too much at the moment. Maybe to be forward compatible? That's right. With the two states "insecure" and "outdated", a bit-array would not add much value, but it would keep future options wide open and still let us distinguish between the options, does not matter if we add two, three or ten new "states" next month :-) Cheers Michael From typo3 at ringerge.org Mon Feb 20 08:51:59 2012 From: typo3 at ringerge.org (Georg Ringer) Date: Mon, 20 Feb 2012 08:51:59 +0100 Subject: [TYPO3-ect] TER clean up actions In-Reply-To: References: Message-ID: Hi, thanks for your efforts, however IMO the time schedule is wrong: First all technical things need to be in place, including the changes in the client TYPO3 version + typo3.org changes and only after that the announcement should start. There have been just too many announcements of things which never got finally done and this should be avoided. Georg From franz at ttproducts.de Mon Feb 20 12:14:18 2012 From: franz at ttproducts.de (Franz Holzinger) Date: Mon, 20 Feb 2012 12:14:18 +0100 Subject: [TYPO3-ect] TER clean up actions In-Reply-To: References: Message-ID: On 19/02/12 11:00, Michael wrote: > On 19/02/12 20:08, Franz Holzinger wrote: >> not whole extensions should be marked as outdated but all old versions >> of these extensions. > > I assume, Jigal meant *versions* of extensions. > > "In the TER database all versions of an extension have their own > record." (quoting Jigal) Same in extensions.xml and in database table > "cache_extensions". > > Should we use the terminology "extension record" in the future (which is > in fact a version of an extension)? Yes, Or lets call it "extension versions". Maybe it is easier to understand what a version is than what the record is. >> Also all extension versions in experimental state should be marked as >> outdated. > > Good point! What's about extensions in "test" and "obsolete" state? I > can't think about a situation where these extensions should come up in > the TER search or in the EM. I think that obsolete is a very similar to outdated. However when an extension is marked as obsolete then AFAIK all versions of it are not visible any more. It should not be possible to upload a new version of an obsolete extension, because the further development of this extension has been given up. All obsolete extensions should always remain outdated. > However, from a logical perspective, test and experimental extensions > are not "outdated" automatically (that would be a wrong definition). So, > I would not suggest that the intended script marks them as outdated, but > we could consider to exclude these states from the TER search and EM by > default, when someone is working on the changes anyway. What do you think? Yes, like obsolete extensions also the exerimental and test extensions should not be listed for a search. > The current list of valid states is: alpha, beta, stable, experimental, > test and obsolete. yes - Franz From steffen.gebert at typo3.org Tue Feb 21 20:29:00 2012 From: steffen.gebert at typo3.org (Steffen Gebert) Date: Tue, 21 Feb 2012 20:29:00 +0100 Subject: [TYPO3-ect] TER clean up actions In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, > First all technical things need to be in place, including the changes in > the client TYPO3 version + typo3.org changes Please keep in mind that it's not possible for an extension author to remove own extensions from TER. I expect that a lot of people want to do this, e.g. because they're not doing TYPO3 anymore and don't want to be asked to update their extension over and over again. I don't know, whether new t3o will support this, but ATM I expect some trouble, if there's no way to do so. So please keep this requirement in mind / on your list :) > There have been just too many announcements of things which never got > finally done and this should be avoided. I really share this opinion! Announce not before everything is ready, please! Besides this: Thanks for your initiative! Kind regards Steffen - -- Steffen Gebert TYPO3 v4 Core Team Member TYPO3 Server Administration Team Member TYPO3 .... inspiring people to share! Get involved: http://typo3.org I work for TYPO3 solely in my spare time. If you think that my work helps you running your business, you are invited to send me a donation via PayPal to this email address. Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPQ/B8AAoJEIskG/rSlyw4IXgH+wYKlmPwiWaq/6zU6uXSC1Vm p/aU9yXxqj0yq7JFVy13+Pgx7gFfJ36ojdxxrA1cuo4A9pzH6stbWsNx0JuUOg// 87LYIy8Zrih2AEyhX7t8pcN+D5CE9zO6r+XVqDFuTmeOJfSua+L86itNMp8syTkr DAE4O7hJrkqdOYAk9rsv5U2Laop2t5vRxDJ0huErAXIVgLN+fS2ElbAd9fYoAsap M2j+7qkXmgjHS2aqhTSQfKaZSLYxR/vZxldKaOdyeE0g/GuKwJ9IpQtZl2tezGVS 1zAr0MchAbsP8CdQvOgITjUqYfjk3JoDMKFNLH+8WW/PaG3L2ZsqV8zd5x/WFuc= =vqzR -----END PGP SIGNATURE----- From typo3 at ringerge.org Tue Feb 21 20:52:44 2012 From: typo3 at ringerge.org (Georg Ringer) Date: Tue, 21 Feb 2012 20:52:44 +0100 Subject: [TYPO3-ect] TER clean up actions In-Reply-To: References: Message-ID: Am 21.02.2012 20:29, schrieb Steffen Gebert: > Please keep in mind that it's not possible for an extension author to > remove own extensions from TER. the code is already there, so someone just needs to adopt it that an author can just remove his own extensions. > Besides this: Thanks for your initiative! I have no initiative here ;) Georg From typo3 at kay-strobach.de Sat Feb 25 10:02:18 2012 From: typo3 at kay-strobach.de (Kay Strobach) Date: Sat, 25 Feb 2012 10:02:18 +0100 Subject: [TYPO3-ect] TER clean up actions In-Reply-To: References: Message-ID: Hi, Am 21.02.2012 20:29, schrieb Steffen Gebert: > Hi, > >> First all technical things need to be in place, including the changes in >> the client TYPO3 version + typo3.org changes +1 > Please keep in mind that it's not possible for an extension author to > remove own extensions from TER. > I expect that a lot of people want to do this, e.g. because they're not > doing TYPO3 anymore and don't want to be asked to update their extension > over and over again. Perhaps we should offer an option to transfer keys to a group of ethusiasts and the extension should than get the status unmaintained ... until there is a person who want's to maintain it. Regards kay -- http://www.kay-strobach.de - Open Source Rocks TYPO3 .... inspiring people to share! Get involved: http://typo3.org Answere was usefull: https://flattr.com/profile/kaystrobach