If eg 2.4.9 binaries could be replaced with 2.5.0 and configuration files won’t need updating, there is no concern.
> On Feb 14, 2022, at 7:35 PM, 张铎 <[email protected]> wrote: > > The new file format is for log4j2, which has a different name, > log4j2.properties. > > When you have log4j.properties and log4j-1.2-api.jar on the classpath, the > log4j1 bridge will take charge and initialize the logging system based on > your log4j.properties. This is my point. > > So in general, if you still want to use log4j.properties file, just remove > the log4j2.properties. If you want to fully migrate to log4j2, then you > need to learn the new grammar and change the log4j2.properties. > > We should mention this in the upgrade section. > > Thanks. > > Andrew Purtell <[email protected]>于2022年2月15日 周二10:52写道： > >>> In the new release version we will provide a new log4j2 format properties >> file >> >> How can we assume users have not changed their log4j properties file? I >> have done it quite often in production. I can't be the only one. >> >>> Even if users have provided their own version of log4j.properties, we >> have log4j-1.2-api, it will read the log4j.properties and initialize the >> logging system based on log4j1 properties file >> >> Pardon me, but based on the new properties file in this patch, that does >> not seem to be true. >> >> I the log4j.properties file we ship now, property names begin with 'log4j'. >> In the new example provided by the log4j2 upgrade patch, property names do >> not begin with 'log4j.' . >> >> Operational compatibility in minor releases means existing configuration >> files should work with no changes required. >> Now, maybe this is a special case, but I do not like the idea of breaking >> users with something dumb like dropping the 'log4j.' prefix from property >> names, if it renders existing properties based configuration nonfunctional. >> So can we bridge this? That is my point. >> >> >>> On Sat, Feb 12, 2022 at 10:30 PM 张铎(Duo Zhang) <[email protected]> >>> wrote: >>> >>> Good news, another approach for implementing LOG4J2-3341 has been landed, >>> and this time it is OK for us to pass hbase.root.logger in. This means >> the >>> most blocker issue for backporting the log4j2 support to branch-2 is >> gone. >>> We could try it once 2.17.2 is out. >>> >>> Andrew Purtell <[email protected]> 于2022年2月8日周二 09:39写道： >>> >>>> When I was looking at the PR I also noticed a potentially annoying and >>>> compatibility breaking problem with the properties file format. Is it >>>> really true that with log4j1 the properties begin with 'log4j.' and >> with >>>> log4j2 the 'log4j.' prefix is removed? If so user configured files >> won't >>> be >>>> compatible unless we can intercept the parse of the file and map the >> one >>> to >>>> the other, somehow. Pardon my ignorance if that would not be necessary >>> and >>>> there is actually a path to compatibility. Anyway I mention it because >> if >>>> it is an issue, for both of these issues, perhaps we can plug something >>> in >>>> rather than rely on the log4j community? It is just a thought... >>>> >>> I do not get the point here. You mean we could do a configuration file >>> translation? In the new release version we will provide a new log4j2 >> format >>> properties file, and I guess for most users they do not need to modify >> this >>> file, just modify hbase-env.sh to control the level and appenders is >>> enough. >>> Even if users have provided their own version of log4j.properties, we >> have >>> log4j-1.2-api, it will read the log4j.properties and initialize the >> logging >>> system based on log4j1 properties file, unless you have implemented your >>> log4j1 appenders. >>> >>>> >>>> On Mon, Feb 7, 2022 at 4:26 PM 张铎(Duo Zhang) <[email protected]> >>>> wrote: >>>> >>>>> Yes, the current solution does not work, they do not want to do >>> variable >>>>> lookup before entering the format free configuration processing step. >>>>> >>>>> Will try to push the log4j community to give another solution. >>>>> >>>>> Thanks. >>>>> >>>>> Andrew Purtell <[email protected]> 于2022年2月8日周二 03:54写道： >>>>> >>>>>> So it looks like LOG4J2-3341 is going to be reverted? Backport >> seems >>>>>> premature until this is resolved with the new solution. >>>>>> >>>>>> On Sat, Feb 5, 2022 at 12:04 PM Andrew Purtell < >> [email protected]> >>>>>> wrote: >>>>>> >>>>>>> Thank you for providing a PR, will review on Monday. >>>>>>> >>>>>>> On Sat, Feb 5, 2022 at 5:16 AM 张铎(Duo Zhang) < >>> [email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> https://github.com/apache/hbase/pull/4096 >>>>>>>> >>>>>>>> The PR based on log4j 2.17.2-SNAPSHOT is ready. >>>>>>>> >>>>>>>> PTAL. >>>>>>>> >>>>>>>> Next I will build the tarball and test whether the logging works >>> as >>>>>>>> expected. >>>>>>>> >>>>>>>> 张铎(Duo Zhang) <[email protected]> 于2022年2月5日周六 16:05写道： >>>>>>>> >>>>>>>>> On the config file format, on master branch I switched to xml >>>>> because >>>>>>>> most >>>>>>>>> log4j2 related resources(for example, answers on >>> stackoverflow...) >>>>> are >>>>>>>> xml >>>>>>>>> based. But LOG4J2-3341 can only work with properties based >>> config >>>>> file >>>>>>>>> format so the plan is to change back to properties file. >>>>>>>>> Of course you still need to tweak the config files, as the >>> config >>>>>> names >>>>>>>>> are not exactly the same, but if we have LOG4J2-3341 then I do >>> not >>>>>> think >>>>>>>>> our users need to tweak the scripts, this is good news at >> least. >>>>>>>>> >>>>>>>>> We have already tried our best to not introduce log4j >>> dependencies >>>>> to >>>>>>>> our >>>>>>>>> downstream users so I think the current branch-2.5 is already >>>>>>>>> 'incompatible' enough for our users as in the old time we were >>>>> likely >>>>>> to >>>>>>>>> pull in log4j and slf4j-log4j if they depend on >>>> hbase-testing-util. >>>>>> But >>>>>>>> for >>>>>>>>> me, I do not think introducing log4j as a dependency is the >>>> correct >>>>>> way >>>>>>>> so >>>>>>>>> I would like to include this and add a section in the release >>>>>>>> announcement >>>>>>>>> to say this. >>>>>>>>> >>>>>>>>> In short, I'm +1 on switching to log4j2 on branch-2.5 and I >> will >>>>> offer >>>>>>>> my >>>>>>>>> help to land the changes. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> Andrew Purtell <[email protected]> 于2022年2月1日周二 02:49写道： >>>>>>>>> >>>>>>>>>> That is good news. >>>>>>>>>> WDYT about integrating this work into branch-2.5 / 2.5.0, and >>>>>>>> branch-2, of >>>>>>>>>> course. Is it compatible enough? Needing to update a >> properties >>>>> file >>>>>>>> and >>>>>>>>>> tweaks to launch scripts, if any, would be fine and can be >>>> handled >>>>>> in a >>>>>>>>>> release note. Switching away from a properties based format >> to >>> an >>>>> XML >>>>>>>>>> format would not (just as example). >>>>>>>>>> >>>>>>>>>> On Sun, Jan 30, 2022 at 4:57 AM 张铎(Duo Zhang) < >>>>> [email protected] >>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Good news, LOG4J2-3341 has been landed. It will be released >>> in >>>>>> log4j >>>>>>>>>>> 2.17.2. >>>>>>>>>>> >>>>>>>>>>> Will start to test it soon. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> 张铎(Duo Zhang) <[email protected]> 于2022年1月25日周二 >> 17:15写道： >>>>>>>>>>> >>>>>>>>>>>> I would prefer we have LOG4J2-3341 first before releasing >>> any >>>>> 2.x >>>>>>>>>>> releases >>>>>>>>>>>> with log4j2. I pinged the log4j community once but no >>>> response >>>>>> yet. >>>>>>>>>> Will >>>>>>>>>>>> try to ping again soon. >>>>>>>>>>>> >>>>>>>>>>>> Andrew Purtell <[email protected]> 于2022年1月25日周二 >>>>> 10:09写道： >>>>>>>>>>>> >>>>>>>>>>>>> Reload4J is a great option when we really should >> maintain >>>>> fairly >>>>>>>>>> strict >>>>>>>>>>>>> compatibility (patch releases) and less so when not >>> (minors, >>>>>>>> majors). >>>>>>>>>>>>> >>>>>>>>>>>>> We haven’t released 2.5.0 yet. My fault, mainly... It’s >>> been >>>>>>>> lagging. >>>>>>>>>>>>> Perhaps we could backport Duo’s work from 3.0.0-alpha >> into >>>>>>>>>> branch-2.5 / >>>>>>>>>>>>> 2.5.0? This would be a minor release, so, while some >>>>> operational >>>>>>>>>>>>> compatibility breaks would be somewhat surprising, it >>> could >>>> be >>>>>>>> more >>>>>>>>>>>>> understandable. >>>>>>>>>>>>> >>>>>>>>>>>>>> On Jan 24, 2022, at 5:00 PM, Zach York < >>> [email protected]> >>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> +1 on the original discussion >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think that all makes sense, we can't know whether >> one >>>>>>>> dependency >>>>>>>>>> is >>>>>>>>>>>>> more >>>>>>>>>>>>>> vulnerable/going to be more work to maintain or not. >>>>> However, >>>>>> I >>>>>>>>>> think >>>>>>>>>>>>>> perhaps the more interesting question is whether we >>> should >>>>> be >>>>>>>> okay >>>>>>>>>>> with >>>>>>>>>>>>>> using EOL dependencies in any active release line. >> CVEs >>>>>>>> happen... I >>>>>>>>>>>>> think >>>>>>>>>>>>>> it's important to be able to react quickly. By >> depending >>>> on >>>>>> any >>>>>>>> EOL >>>>>>>>>>>>> code in >>>>>>>>>>>>>> our active release lines, we severely limit our >> ability >>> to >>>>>>>> quickly >>>>>>>>>>> deal >>>>>>>>>>>>>> with CVEs. I understand it's not always easy (the >>>> backwards >>>>>>>>>>>>> incompatibility >>>>>>>>>>>>>> of log4j2 and the properties files are good examples), >>> but >>>>>> it's >>>>>>>>>> also >>>>>>>>>>>>> been >>>>>>>>>>>>>> 6+ years since log4j 1.x has become EOL. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Jan 21, 2022 at 11:47 AM Andrew Purtell < >>>>>>>>>> [email protected] >>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I will offer a guess as answer to the question >>> originally >>>>>>>>>> proposed, >>>>>>>>>>>>> which >>>>>>>>>>>>>>> is, no the Logging PMC is not going to behave in a >>>>>> cooperative >>>>>>>>>> manner >>>>>>>>>>>>> to >>>>>>>>>>>>>>> Reload4J. The best we can hope for, and I personally >>>> doubt >>>>>> it, >>>>>>>> is >>>>>>>>>>> they >>>>>>>>>>>>> will >>>>>>>>>>>>>>> not be actively hostile. Decisions made by Apache PMC >>> can >>>>>>>>>>>>> unfortunately be >>>>>>>>>>>>>>> made on the basis of years-long running arguments and >>>>>>>> personality >>>>>>>>>>>>>>> conflicts, and Logging is unfortunately one of them. >>> Just >>>>> my >>>>>>>>>> opinion. >>>>>>>>>>>>> You >>>>>>>>>>>>>>> won't change it. Fortunately that is neither here nor >>>>> there. >>>>>> We >>>>>>>>>>> aren't >>>>>>>>>>>>> here >>>>>>>>>>>>>>> to judge up front if Reload4J can respond adequately >> to >>>>>>>>>> hypothetical >>>>>>>>>>>>> future >>>>>>>>>>>>>>> security issues. That is not knowable and remains to >> be >>>>> seen. >>>>>>>> It >>>>>>>>>> also >>>>>>>>>>>>>>> remains to be seen if Log4J 2 is going to respond >>>>> adequately >>>>>> to >>>>>>>>>>> future >>>>>>>>>>>>>>> security issues. Or Netty. Or Jersey. Or Jackson. Or >>> any >>>> of >>>>>> our >>>>>>>>>> other >>>>>>>>>>>>> risky >>>>>>>>>>>>>>> third party dependencies (as measured by having >>>>> "interesting" >>>>>>>>>> CVEs). >>>>>>>>>>>>> What >>>>>>>>>>>>>>> we can do is look at the current track record, which >>> has >>>>> been >>>>>>>>>>> adequate >>>>>>>>>>>>> so >>>>>>>>>>>>>>> far. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Jan 21, 2022 at 11:35 AM Wei-Chiu Chuang >>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The reload4j is maintained by one of the Apache >>> Logging >>>>> PMC. >>>>>>>> And >>>>>>>>>> a >>>>>>>>>>>>>>> release >>>>>>>>>>>>>>>> was made to address the latest log4j 1.x CVEs >>> announced >>>>>> only a >>>>>>>>>> day >>>>>>>>>>>>> after. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is a thread in the private@logging that >>> mentioned >>>>> the >>>>>>>>>> “new” >>>>>>>>>>>>>>> log4j1.x >>>>>>>>>>>>>>>> CVEs were actually not new. They were announced >> years >>>>> before >>>>>>>> for >>>>>>>>>> 2.x >>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>> happens to also impact 1.x. But because 1.x was >>>> considered >>>>>>>> EOL, >>>>>>>>>> they >>>>>>>>>>>>>>> didn’t >>>>>>>>>>>>>>>> bother to mention 1.x were affected. It is only now >>> that >>>>>> 1.x’s >>>>>>>>>>> getting >>>>>>>>>>>>>>>> interest that they did this. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sean Busbey <[email protected]>於 2022年1月22日 >>>> 週六，上午2:47寫道： >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It's relevant to what kind of mitigation this is. >> The >>>>>>>>>> effectiveness >>>>>>>>>>>>> of >>>>>>>>>>>>>>>>> reload4j to deal with "the critical CVEs of log4j >> 1" >>> is >>>>>>>> limited >>>>>>>>>> by >>>>>>>>>>>>> how >>>>>>>>>>>>>>>>> likely it is that they know about them. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Otherwise at the next CVE we're back in the same >>> place >>>>>> where >>>>>>>>>>>>> downstream >>>>>>>>>>>>>>>>> users aren't meaningfully more protected. And in >> that >>>>> case >>>>>>>>>> perhaps >>>>>>>>>>> we >>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>> do better for our users by e.g. putting more >> emphasis >>>>>>>> upgrading >>>>>>>>>>>>> across >>>>>>>>>>>>>>>> our >>>>>>>>>>>>>>>>> releases or providing breaking changes to get the >>> pain >>>>> over >>>>>>>>>> with. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Fri, Jan 21, 2022 at 11:03 AM Andrew Purtell < >>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> That does not seem germane to this discussion. We >>>> don’t >>>>>>>>>>> investigate >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> attempt to manage the security reporting >> arrangement >>>> of >>>>>> any >>>>>>>> of >>>>>>>>>> our >>>>>>>>>>>>>>>> other >>>>>>>>>>>>>>>>>> third party dependencies. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Jan 21, 2022, at 7:59 AM, Sean Busbey < >>>>>>>> [email protected]> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Has anyone asked the ASF Logging PMC if they'll >>>>> forward >>>>>>>>>> security >>>>>>>>>>>>>>>>> reports >>>>>>>>>>>>>>>>>>> against log4j 1 to the reload4j project? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 21, 2022 at 3:33 AM Pankaj Kumar < >>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> +1 for reload4j. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>> Pankaj >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) < >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Already filed HBASE-26691. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Wei-Chiu Chuang <[email protected]> >>> 于2022年1月21日周五 >>>>>>>> 16:53写道： >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> +1 I am doing the same in Hadoop. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 21, 2022 at 4:51 PM Viraj Jasani < >>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> +1 for Reload4J migration in active release >>>>> branches. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew >>> Purtell < >>>>>>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 for migrating to Reload4J. It is binary >> and >>>>>>>>>> configuration >>>>>>>>>>>>>>>>>>>>> compatible >>>>>>>>>>>>>>>>>>>>>>>> with log4j 1 so meets our compatibility >>>>> guidelines. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> If this is an agreeable plan I can make the >>>>> changes >>>>>>>> in a >>>>>>>>>> PR >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>>>>> do >>>>>>>>>>>>>>>>>>>>>>>> a round of new releases. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Jan 20, 2022, at 10:16 PM, Duo Zhang < >>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On master we have already migrated to >>> log4j2, >>>>> but >>>>>>>> for >>>>>>>>>> all >>>>>>>>>>>>>>>> other >>>>>>>>>>>>>>>>>>>>>>> release >>>>>>>>>>>>>>>>>>>>>>>>> lines we are still on log4j1. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Recently there are several new CVEs for >>> log4j1, >>>>> so >>>>>> I >>>>>>>>>> think >>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>>>> also >>>>>>>>>>>>>>>>>>>>>>>>> address them for release lines other than >>>> master. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> One possible solution is to also migrate >>> log4j2 >>>>> but >>>>>>>> use >>>>>>>>>>>>>>> log4j12 >>>>>>>>>>>>>>>>>>>>>> bridge >>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>> maintain the compatibility, but we have >>> already >>>>>> known >>>>>>>>>> that >>>>>>>>>>>>>>>>>>>> log4j12 >>>>>>>>>>>>>>>>>>>>>>> bridge >>>>>>>>>>>>>>>>>>>>>>>>> can not work perfectly with hadoop, as >> hadoop >>>> has >>>>>>>> some >>>>>>>>>>>>>>>> customized >>>>>>>>>>>>>>>>>>>>>>> log4j1 >>>>>>>>>>>>>>>>>>>>>>>>> appender implementations, which inherit >> some >>>>> log4j1 >>>>>>>>>>> appenders >>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>> part of the log4j12 bridge. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Reload4j is a fork of the log4j1 and has >>> fixed >>>>> the >>>>>>>>>> critical >>>>>>>>>>>>>>>> CVEs, >>>>>>>>>>>>>>>>>>>>> so >>>>>>>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>> less hurt to replace log4j with reload4j. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Suggestions are welcomed. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks. Regards >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Andrew >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Unrest, ignorance distilled, nihilistic imbeciles - >>>>>>>>>>>>>>> It's what we’ve earned >>>>>>>>>>>>>>> Welcome, apocalypse, what’s taken you so long? >>>>>>>>>>>>>>> Bring us the fitting end that we’ve been counting on >>>>>>>>>>>>>>> - A23, Welcome, Apocalypse >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Best regards, >>>>>>>>>> Andrew >>>>>>>>>> >>>>>>>>>> Unrest, ignorance distilled, nihilistic imbeciles - >>>>>>>>>> It's what we’ve earned >>>>>>>>>> Welcome, apocalypse, what’s taken you so long? >>>>>>>>>> Bring us the fitting end that we’ve been counting on >>>>>>>>>> - A23, Welcome, Apocalypse >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Andrew >>>>>>> >>>>>>> Unrest, ignorance distilled, nihilistic imbeciles - >>>>>>> It's what we’ve earned >>>>>>> Welcome, apocalypse, what’s taken you so long? >>>>>>> Bring us the fitting end that we’ve been counting on >>>>>>> - A23, Welcome, Apocalypse >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Andrew >>>>>> >>>>>> Unrest, ignorance distilled, nihilistic imbeciles - >>>>>> It's what we’ve earned >>>>>> Welcome, apocalypse, what’s taken you so long? >>>>>> Bring us the fitting end that we’ve been counting on >>>>>> - A23, Welcome, Apocalypse >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Andrew >>>> >>>> Unrest, ignorance distilled, nihilistic imbeciles - >>>> It's what we’ve earned >>>> Welcome, apocalypse, what’s taken you so long? >>>> Bring us the fitting end that we’ve been counting on >>>> - A23, Welcome, Apocalypse >>>> >>> >> >> >> -- >> Best regards, >> Andrew >> >> Unrest, ignorance distilled, nihilistic imbeciles - >> It's what we’ve earned >> Welcome, apocalypse, what’s taken you so long? >> Bring us the fitting end that we’ve been counting on >> - A23, Welcome, Apocalypse >>
