Could someone add note which *IDE packages* built by eclipse.org include affected log4j2 and which versions of those packages are vulnerable?
Am 13. Dezember 2021 22:45:35 MEZ schrieb Denis Roy <denis....@eclipse-foundation.org>: >I am going to crowd-source this. I need everyone to chime in on this >Wiki page: > >https://wiki.eclipse.org/Eclipse_and_log4j2_vulnerability_(CVE-2021-44228) > > >I will see that this information gets broadcast tomorrow, once there is >some information in the table. > > >Denis > > >On 2021-12-13 15:03, Jonah Graham wrote: >> Denis, >> >> It is the log4j vulnerability, the fact that it doesn't affect some >> versions of log4j is in the vulnerability description. Please continue >> doing this - I appreciate it. >> >> Most media reports call it simply log4j - but you can reduce the noise >> by calling it "Eclipse and log4j2 vulnerability (CVE-2021-44228)" >> >> Ed, >> >> I am delighted that we are dependent on a version of log4j that >> doesn't have this problem - but I wouldn't get too excited about >> promoting that Eclipse IDE hasn't updated a dependency. log4j 1.2 has >> been EOL for 6+ years (https://logging.apache.org/log4j/1.2/). I am >> glad this vulnerability doesn't exist, but log4j 1.2 does have its own >> problems - like CVE-2019-17571 - so nothing to get too excited about. >> >> Jonah >> >> ~~~ >> Jonah Graham >> Kichwa Coders >> www.kichwacoders.com <http://www.kichwacoders.com> >> >> >> On Mon, 13 Dec 2021 at 14:50, Denis Roy >> <denis....@eclipse-foundation.org> wrote: >> >> IANAD so perhaps I'm the worst possible person to be doing this. >> >> >> >> On 2021-12-13 14:47, Ed Willink wrote: >>> >>> Hi >>> >>> Maybe the CVE is also misleading or the discussion here is very >>> wrong. The current Orbit repo contains >>> >>> org.apache.log4j 1.2.15 is clearly not log4j2. It has been in use >>> unchanged in every Eclipse distribution for at least the last ten >>> years. >>> >>> The analysis on this thread has been about >>> org.apache.logging.log4j which could be a log4j2. It is unused in >>> core and many Eclipse configurations. >>> >>> Please be precise. >>> >>> Regards >>> >>> Ed Willink >>> >>> On 13/12/2021 19:33, Denis Roy wrote: >>>> >>>> The CVE shows: Apache Log4j2 >>>> >>>> I would assume that is correct. >>>> >>>> >>>> On 2021-12-13 14:31, Ed Willink wrote: >>>>> >>>>> Hi >>>>> >>>>> Please start by correctly referencing the vulnerability. >>>>> >>>>> It is with org.apache.logging.log4j, >>>>> >>>>> There is no issue with org.apache.log4j so continually >>>>> referring to this as a log4j vulnerability is very misleading. >>>>> >>>>> AFAICT no Eclipse installation of mine has ever included >>>>> org.apache.logging.log4j. >>>>> >>>>> Regards >>>>> >>>>> Ed Willink >>>>> >>>>> On 13/12/2021 19:15, Denis Roy wrote: >>>>>> >>>>>> How about I start: >>>>>> >>>>>> >>>>>> title: *Eclipse and log4j vulnerability **(CVE-2021-442280)* >>>>>> >>>>>> Here is the status of the various Eclipse Foundation projects, >>>>>> with regards to CVE-2021-442280: >>>>>> >>>>>> >>>>>> - Eclipse IDE 2021-12: *not vulnerable* >>>>>> >>>>>> - Eclipse Jetty (version): status >>>>>> >>>>>> - Eclipse GlassFish (version): status >>>>>> >>>>>> - Eclipse jGit (version): status >>>>>> >>>>>> >>>>>> We would likely need to get the input from other projects, to >>>>>> "self-certify". I can do this by reaching out to >>>>>> eclipse.org-committers if anyone agrees. >>>>>> >>>>>> At this point, most of Europe is logged out for the day, and >>>>>> time is ticking away fast for this sort of action. >>>>>> >>>>>> >>>>>> Denis >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2021-12-13 14:00, Jonah Graham wrote: >>>>>>> Hi Denis, >>>>>>> >>>>>>> Yes - that seems best. I can help with the actual story - as >>>>>>> can others on this list (I hope :-). >>>>>>> >>>>>>> Jonah >>>>>>> ~~~ >>>>>>> Jonah Graham >>>>>>> Kichwa Coders >>>>>>> www.kichwacoders.com <http://www.kichwacoders.com> >>>>>>> >>>>>>> >>>>>>> On Mon, 13 Dec 2021 at 13:58, Denis Roy >>>>>>> <denis....@eclipse-foundation.org> wrote: >>>>>>> >>>>>>> Good question. >>>>>>> >>>>>>> If we agree on a story (ie, if someone can help me write >>>>>>> what the actual story is), I can certainly post a blog >>>>>>> post on the blogs.eclipse.org <http://blogs.eclipse.org> >>>>>>> domain. From there, we could tweet about it from the >>>>>>> official @EclipseFdn twitter account, and perhaps add >>>>>>> links to the post from the Newcomers forum. >>>>>>> >>>>>>> Does that seem acceptable? >>>>>>> >>>>>>> >>>>>>> Denis >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2021-12-13 13:44, Jonah Graham wrote: >>>>>>>> Thanks everyone for working on this - I think we have a >>>>>>>> pretty good story now about what the Eclipse IDE / >>>>>>>> SimRel has done for the log4j vulnerability. >>>>>>>> >>>>>>>> The last thing is to say so in a concise way - where >>>>>>>> can/should we say so (besides this mailing list)? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jonah >>>>>>>> ~~~ >>>>>>>> Jonah Graham >>>>>>>> Kichwa Coders >>>>>>>> www.kichwacoders.com <http://www.kichwacoders.com> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, 13 Dec 2021 at 12:58, Ed Merks >>>>>>>> <ed.me...@gmail.com> wrote: >>>>>>>> >>>>>>>> Christoph, >>>>>>>> >>>>>>>> I really appreciate your creative ideas. I think >>>>>>>> "we, i.e., as an I" >>>>>>>> should indeed plan long term for the possibility of >>>>>>>> expedient mitigation >>>>>>>> of such problems in the future using this type of >>>>>>>> approach. >>>>>>>> >>>>>>>> For the project catalogs I've regenerated them such >>>>>>>> than installing any >>>>>>>> version of the RCP package (with any installer) will >>>>>>>> install the latest >>>>>>>> version of Passage which strictly requires the >>>>>>>> updated/fix version of >>>>>>>> org.apache.logging.log4j. Also any >>>>>>>> installer-created RCP package >>>>>>>> installation will ask to update itself upon >>>>>>>> startup/restart. >>>>>>>> >>>>>>>> >>>>>>>> https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=929d140afc34ecdb85b7996c63ce0b36b6723a34 >>>>>>>> >>>>>>>> Another thought I had is that the donation support >>>>>>>> I've added opens a >>>>>>>> browser page. In this case we could change the URL >>>>>>>> such that a page >>>>>>>> with information about this CVE could be presented... >>>>>>>> >>>>>>>> But now it's late in the day and I'm done for now. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Ed >>>>>>>> >>>>>>>> On 13.12.2021 18:03, Christoph Läubrich wrote: >>>>>>>> > Hi Ed, >>>>>>>> > >>>>>>>> > > One problem is we don't know all the things that >>>>>>>> strictly require the >>>>>>>> > > older bundle. >>>>>>>> > >>>>>>>> > In the end what matters is that the bundle is no >>>>>>>> longer available. If >>>>>>>> > we don't uninstall them at laes they won't resolve >>>>>>>> anymore and people >>>>>>>> > will go to the project website, report an issue >>>>>>>> and/or install an >>>>>>>> > update :-) >>>>>>>> > >>>>>>>> > > In the end it at the simplest, it could just be >>>>>>>> a feature with p2.inf >>>>>>>> > > with negative requirements for bundles that have >>>>>>>> been determined to be >>>>>>>> > > unsafe. >>>>>>>> > >>>>>>>> > yep that's what I have had in mind, I think it >>>>>>>> would be cool to have >>>>>>>> > one global feature "CVE Mitigation" or something >>>>>>>> and this >>>>>>>> > requires/includes individual CVE features that >>>>>>>> ship with appropriate >>>>>>>> > p2.inf items. >>>>>>>> > Thus way, once added to an IDE this will enable us >>>>>>>> to make CVE fixes >>>>>>>> > available tor a broad audience and make people >>>>>>>> more aware of them >>>>>>>> > through the update capabilities of eclipse itself. >>>>>>>> > >>>>>>>> > >> What do you think does this sounds reasonable? >>>>>>>> > > It's a creative idea. I like it. >>>>>>>> > >>>>>>>> > Good to hear! As you probably know much more about >>>>>>>> p2.inf magic than >>>>>>>> > me can you craft such a feature so we can >>>>>>>> investigate this more? As >>>>>>>> > mentioned before this is more an idea so I can't >>>>>>>> shar any concrete >>>>>>>> > code samples yet and have no idea where this would >>>>>>>> bes be placed (part >>>>>>>> > of the platform cbi? github/gitlab project under >>>>>>>> eclipse umbrella? >>>>>>>> > eclipse cbi maybe?) >>>>>>>> > >>>>>>>> > >>>>>>>> > Am 13.12.21 um 17:48 schrieb Ed Merks: >>>>>>>> >> Christoph, >>>>>>>> >> >>>>>>>> >> Comments below. >>>>>>>> >> >>>>>>>> >> On 13.12.2021 17:29, Christoph Läubrich wrote: >>>>>>>> >>> Hi Ed, >>>>>>>> >>> >>>>>>>> >>> I wonder if it would not be possible to publish >>>>>>>> a general purpose >>>>>>>> >>> "CVE mitigation" Updatesite everyone could add >>>>>>>> to an existing >>>>>>>> >>> eclipse install. >>>>>>>> >> Of course not everyone has Passage installed, nor >>>>>>>> this specific >>>>>>>> >> bundle... >>>>>>>> >>> >>>>>>>> >>> Such an Updatesite could contain a Unit for a >>>>>>>> given CVE (e.g. >>>>>>>> >>> CVE-2021-44228 in this case) that defines a >>>>>>>> negative requirement on >>>>>>>> >>> any affected version (in this case any >>>>>>>> org.apache.logging.log4j with >>>>>>>> >>> version range < 2.15). >>>>>>>> >> Yes that's theoretically possible. (And in the >>>>>>>> catalog I can easily >>>>>>>> >> do this, but not all installation are installed >>>>>>>> from the catalog.) >>>>>>>> >>> >>>>>>>> >>> What will happen then is that P2 will give the >>>>>>>> user the choice to >>>>>>>> >>> install this mitigation unit and uninstall >>>>>>>> >> P2 generally wants to install features so such a >>>>>>>> thing would need to >>>>>>>> >> be packaged up as a feature... >>>>>>>> >>> >>>>>>>> >>> a) the dangerous bundle >>>>>>>> >>> b) any dependent and affected unit (passage in >>>>>>>> this case) >>>>>>>> >>> >>>>>>>> >>> from the current IDE. >>>>>>>> >> One problem is we don't know all the things that >>>>>>>> strictly require the >>>>>>>> >> older bundle. The parts of Passage contributed >>>>>>>> to the train only >>>>>>>> >> have lower bounds, but there are Passage features >>>>>>>> that include this >>>>>>>> >> bundle with an exact range... >>>>>>>> >>> >>>>>>>> >>> Once an Update is in place, passage could be >>>>>>>> installed (e.g. with a >>>>>>>> >>> separate update-site) again including a fixed >>>>>>>> version of the >>>>>>>> >>> problematic dependecy. >>>>>>>> >>> >>>>>>>> >> Another question is what else out there that >>>>>>>> might already be >>>>>>>> >> installed depend on logging.log4j and would also >>>>>>>> need to be updated >>>>>>>> >> or uninstalled? That's an open ended question... >>>>>>>> >>> Even though such a site would currently need >>>>>>>> some kind of >>>>>>>> >>> handcrafted metadata, we could enhance this so >>>>>>>> we probably once have >>>>>>>> >>> some automatic import of CVE from public >>>>>>>> databases and automatic >>>>>>>> >>> notification of users about new CVE affecting >>>>>>>> their IDE. >>>>>>>> >>> >>>>>>>> >> Yes, such a thing will follow some pattern so >>>>>>>> generating such a thing >>>>>>>> >> would be good... >>>>>>>> >>> Including such a site in a target platform of a >>>>>>>> build could >>>>>>>> >>> effectively fail the build (and make projects >>>>>>>> automatically aware of >>>>>>>> >>> new problems) as they arise, also preventing one >>>>>>>> from including >>>>>>>> >>> problematic dependencies in the future. >>>>>>>> >> In the end it at the simplest, it could just be a >>>>>>>> feature with p2.inf >>>>>>>> >> with negative requirements for bundles that have >>>>>>>> been determined to >>>>>>>> >> be unsafe. >>>>>>>> >>> What do you think does this sounds reasonable? >>>>>>>> >> It's a creative idea. I like it. >>>>>>>> >>> Am 12.12.21 um 14:07 schrieb Ed Merks: >>>>>>>> >>>> Alexander, >>>>>>>> >>>> >>>>>>>> >>>> Will you set the lower bound to force the fixed >>>>>>>> version and to >>>>>>>> >>>> disallow the older version? >>>>>>>> >>>> >>>>>>>> >>>> If only the installer and its product catalogs >>>>>>>> were involved, I >>>>>>>> >>>> could fix the problem easily by adding an >>>>>>>> update site and forcing >>>>>>>> >>>> the version range to install the fixed >>>>>>>> version. I wouldn't even >>>>>>>> >>>> need a new version of Passage to force/fix that... >>>>>>>> >>>> >>>>>>>> >>>> But we're also talking about the release train >>>>>>>> repository, which >>>>>>>> >>>> would need a respin. Unfortunately there are >>>>>>>> updates in the SimRel >>>>>>>> >>>> repo after the 2021-12 tag: >>>>>>>> >>>> >>>>>>>> >>>> Some of those will be needed because the >>>>>>>> >>>> >>>>>>>> https://download.eclipse.org/eclipse/updates/4.22-I-builds >>>>>>>> >>>>>>>> >>>> repository is gone. Hopefully other projects >>>>>>>> contributed stable >>>>>>>> >>>> repositories with unchanging released content >>>>>>>> rather than pointing >>>>>>>> >>>> at "moving target" that has changed its content >>>>>>>> since the release. >>>>>>>> >>>> >>>>>>>> >>>> If we decide we need to do a respin and we >>>>>>>> accomplish that, then >>>>>>>> >>>> EPP needs to respin as well. This will be >>>>>>>> something the Planning >>>>>>>> >>>> Council will need to discuss and to decide >>>>>>>> which actions to take. >>>>>>>> >>>> >>>>>>>> >>>> Only you know how Passage uses the logging >>>>>>>> facility to know if >>>>>>>> >>>> there is in actual fact a risk. I.e., is >>>>>>>> Passage actually logging >>>>>>>> >>>> information obtained from an internet >>>>>>>> connection and is that >>>>>>>> >>>> actually enabled/activated in the RCP/RAP >>>>>>>> package itself? I.e., >>>>>>>> >>>> does what Jens Lideström outlined apply? >>>>>>>> (Thanks Jens!) If not, >>>>>>>> >>>> then perhaps we're unduly alarmed. I could see >>>>>>>> nothing that >>>>>>>> >>>> appears to be related to Passage in an IDE into >>>>>>>> which I installed >>>>>>>> >>>> Passage, i.e., no preferences, no wizards, no >>>>>>>> views, nothing >>>>>>>> >>>> obvious. Is it perhaps the case that the >>>>>>>> security problems would >>>>>>>> >>>> only manifest themselves in applications where >>>>>>>> Passage is deployed >>>>>>>> >>>> at runtime for licensing control of that >>>>>>>> application? >>>>>>>> >>>> >>>>>>>> >>>> Please try to outline the risk factors of >>>>>>>> Passage's development >>>>>>>> >>>> tools being installed in a IDE application to >>>>>>>> help inform the >>>>>>>> >>>> Planning Council in making a decision. >>>>>>>> >>>> >>>>>>>> >>>> P.S., Passage in the only component on the >>>>>>>> 2021-12 train that is >>>>>>>> >>>> affected; I cannot comment on all >>>>>>>> Eclipse-distributed content in >>>>>>>> >>>> general... >>>>>>>> >>>> >>>>>>>> >>>> Regards, >>>>>>>> >>>> Ed >>>>>>>> >>>> >>>>>>>> >>>> On 12.12.2021 11:04, Alexander Fedorov wrote: >>>>>>>> >>>>> Passage Team is working to provide Eclipse >>>>>>>> Passage 2.2.1 that will >>>>>>>> >>>>> consume fixed logger from >>>>>>>> >>>>> >>>>>>>> >>>>>>>> https://download.eclipse.org/tools/orbit/downloads/drops2/I20211211225428/repository >>>>>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> Ed, how could we then provide an update for >>>>>>>> released SimRel 2021-12? >>>>>>>> >>>>> >>>>>>>> >>>>> Regards, >>>>>>>> >>>>> AF >>>>>>>> >>>>> >>>>>>>> >>>>> P.S. I'm really surprised to have the only >>>>>>>> component affected >>>>>>>> >>>>> after having org.apache.*logging**.log4j 2.8.2 >>>>>>>> *published in >>>>>>>> >>>>> Eclipse Orbit starting from 2020-09 (6 releases). >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> 12/12/2021 12:41 PM, Ed Merks пишет: >>>>>>>> >>>>>> >>>>>>>> >>>>>> Just to avoid any confusion such as that >>>>>>>> which Ed Willink >>>>>>>> >>>>>> mentioned, the >>>>>>>> >>>>>> >>>>>>>> >>>>>>>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228 >>>>>>>> >>>>>>>> >>>>>> issue is specifically about the class >>>>>>>> >>>>>> >>>>>>>> org.apache.logging.log4j.core/lookup.JndiLookup.which >>>>>>>> is not in a >>>>>>>> >>>>>> package provided by org.apache.*log4j *but >>>>>>>> rather in a package >>>>>>>> >>>>>> provided by org.apache.*logging**.log4j *as >>>>>>>> illustrated here in a >>>>>>>> >>>>>> CBI p2 aggregator repo view: >>>>>>>> >>>>>> >>>>>>>> >>>>>> Based on the analysis tool I've been >>>>>>>> developing for better >>>>>>>> >>>>>> managing SimRel, e.g., to provide >>>>>>>> traceability and dependency >>>>>>>> >>>>>> analysis, it's definitely the case that only >>>>>>>> Passage depends on >>>>>>>> >>>>>> this bundle: >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Specifically via bundle requirements (as >>>>>>>> opposed to package >>>>>>>> >>>>>> requirements): >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Those requirements have no upper bound, only >>>>>>>> an inclusive lower >>>>>>>> >>>>>> bound, such that they will resolve and use >>>>>>>> any higher version of >>>>>>>> >>>>>> org.apache.logging.log4j. As such, >>>>>>>> installing Passage with >>>>>>>> >>>>>> >>>>>>>> >>>>>>>> https://download.eclipse.org/tools/orbit/downloads/drops2/I20211211225428/repository >>>>>>>> >>>>>>>> >>>>>> in the available sites and enabling to use >>>>>>>> those, does install >>>>>>>> >>>>>> the newer version: >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> The bad news is that the RCP/RAP package >>>>>>>> contains Passage and >>>>>>>> >>>>>> hence the bad version of the >>>>>>>> org.apache.logging.log4j bundle. >>>>>>>> >>>>>> >>>>>>>> >>>>>> What's not clear is whether Passage actually >>>>>>>> logs messages whose >>>>>>>> >>>>>> content can be externally subverted/exploited >>>>>>>> via contact to the >>>>>>>> >>>>>> web and whether such actions are activity is >>>>>>>> actually enabled by >>>>>>>> >>>>>> default, e.g., in the RCP/RAP package... >>>>>>>> >>>>>> >>>>>>>> >>>>>> Regards, >>>>>>>> >>>>>> Ed >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> On 11.12.2021 20:48, Gunnar Wagenknecht wrote: >>>>>>>> >>>>>>> Thanks Matthias! >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> According to Wayne, 2.15 has already been >>>>>>>> vetted and is good for >>>>>>>> >>>>>>> use: >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> https://www.eclipse.org/lists/eclipse.org-committers/msg01333.html >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> -Gunnar >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> -- >>>>>>>> >>>>>>> Gunnar Wagenknecht >>>>>>>> >>>>>>> gun...@wagenknecht.org, http://guw.io/ >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Dec 11, 2021, at 20:36, Matthias Sohn >>>>>>>> >>>>>>>> <matthias.s...@gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Dec 11, 2021 at 11:35 AM Gunnar >>>>>>>> Wagenknecht >>>>>>>> >>>>>>>> <gun...@wagenknecht.org> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Alexander, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Dec 11, 2021, at 10:16, Alexander >>>>>>>> Fedorov >>>>>>>> >>>>>>>>> <alexander.fedo...@arsysop.ru> wrote: >>>>>>>> >>>>>>>>> It would be great to learn >>>>>>>> vulnerability clean-up process >>>>>>>> >>>>>>>>> with >>>>>>>> >>>>>>>>> Eclipse Orbit team to then apply it to >>>>>>>> Eclipse Passage. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> There is no Orbit team. Orbit is driven by >>>>>>>> project committers >>>>>>>> >>>>>>>> using/needing libraries in Orbit. >>>>>>>> >>>>>>>> I encourage the Eclipse Passage project >>>>>>>> to submit a Gerrit >>>>>>>> >>>>>>>> review for a newer version. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> considering the buzz around this >>>>>>>> vulnerability I went ahead and >>>>>>>> >>>>>>>> pushed an update to log4j 2.15 for orbit >>>>>>>> >>>>>>>> >>>>>>>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188768 >>>>>>>> >>>>>>>> note that the required clearlydefined score >>>>>>>> isn't reached yet, >>>>>>>> >>>>>>>> if this doesn't change soon >>>>>>>> >>>>>>>> maybe someone can contribute the missing >>>>>>>> information to >>>>>>>> >>>>>>>> clearlydefined or >>>>>>>> >>>>>>>> we file CQs to get the license approval for >>>>>>>> the new version >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> You can also try a new way as described by >>>>>>>> Mickael here: >>>>>>>> >>>>>>>> >>>>>>>> https://www.eclipse.org/lists/orbit-dev/msg05509.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> To unsubscribe from this list, >> visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Kind regards, Andrey Loskutov https://www.eclipse.org/user/aloskutov Спасение утопающих - дело рук самих утопающих _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
