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 <apurt...@apache.org>于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) <palomino...@gmail.com> > 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 <apurt...@apache.org> 于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) <palomino...@gmail.com> > > > 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 <apurt...@apache.org> 于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 < > apurt...@apache.org> > > > > > wrote: > > > > > > > > > > > Thank you for providing a PR, will review on Monday. > > > > > > > > > > > > On Sat, Feb 5, 2022 at 5:16 AM 张铎(Duo Zhang) < > > palomino...@gmail.com> > > > > > > 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) <palomino...@gmail.com> 于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 <apurt...@apache.org> 于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) < > > > > palomino...@gmail.com > > > > > > > > > > > >> >> 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) <palomino...@gmail.com> 于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 <andrew.purt...@gmail.com> 于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 < > > zy...@apache.org> > > > > > >> 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 < > > > > > >> >> apurt...@apache.org > > > > > >> >> > > > > > > > >> >> > >> 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 > > > > > >> >> > >> >> <weic...@cloudera.com.invalid> 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 <bus...@apache.org>於 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 < > > > > > >> >> > >> >>> andrew.purt...@gmail.com> > > > > > >> >> > >> >>>> 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 < > > > > > >> bus...@apache.org> > > > > > >> >> > >> >> 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 < > > > > > >> >> > >> >>> pankajku...@apache.org> > > > > > >> >> > >> >>>>> wrote: > > > > > >> >> > >> >>>>>>> > > > > > >> >> > >> >>>>>>> +1 for reload4j. > > > > > >> >> > >> >>>>>>> > > > > > >> >> > >> >>>>>>> Regards, > > > > > >> >> > >> >>>>>>> Pankaj > > > > > >> >> > >> >>>>>>> > > > > > >> >> > >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) < > > > > > >> >> > >> >> palomino...@gmail.com > > > > > >> >> > >> >>>> > > > > > >> >> > >> >>>>> wrote: > > > > > >> >> > >> >>>>>>>> > > > > > >> >> > >> >>>>>>>> Already filed HBASE-26691. > > > > > >> >> > >> >>>>>>>> > > > > > >> >> > >> >>>>>>>> Wei-Chiu Chuang <weic...@apache.org> > > 于2022年1月21日周五 > > > > > >> 16:53写道： > > > > > >> >> > >> >>>>>>>> > > > > > >> >> > >> >>>>>>>>> +1 I am doing the same in Hadoop. > > > > > >> >> > >> >>>>>>>>> > > > > > >> >> > >> >>>>>>>>> On Fri, Jan 21, 2022 at 4:51 PM Viraj Jasani < > > > > > >> >> > >> >> vjas...@apache.org> > > > > > >> >> > >> >>>>>>> wrote: > > > > > >> >> > >> >>>>>>>>> > > > > > >> >> > >> >>>>>>>>>> +1 for Reload4J migration in active release > > > > branches. > > > > > >> >> > >> >>>>>>>>>> > > > > > >> >> > >> >>>>>>>>>> > > > > > >> >> > >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew > > Purtell < > > > > > >> >> > >> >>>>>>>>> andrew.purt...@gmail.com> > > > > > >> >> > >> >>>>>>>>>> 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 < > > > > > >> >> > zhang...@apache.org > > > > > >> >> > >> >>> > > > > > >> >> > >> >>>>>>>> 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 >
