Re: [arch-general] gnupg version

[mpan]

hello. GnuPG 2.2.25 has been released it fixes bug which affects me. but 
arch only has Version 2.2.24-1 in testing. my question is why it haven't 
been updated? if the maintainer simply does not have time yet, then I 
understand, but maybe there is another reason?
  There is only one bug fixed between 2.2.24 and 2.2.25, and it 
introduces 3 lines of code:


 DIFF --
diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 6245a5331..ec60db2e6 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -4392,10 +4392,15 @@ check_keyidstr (app_t app, const char *keyidstr, 
int keyno, int *r_use_auth)

   const char *s;
   int n;
   const char *fpr = NULL;
+  int i;

   if (r_use_auth)
 *r_use_auth = 0;

+  /* Make sure we have load the public keys.  */
+  for (i = 0; i < 3; i++)
+get_public_key (app, i);
+
   if (strlen (keyidstr) < 32)
 return gpg_error (GPG_ERR_INV_ID);
   else
- /DIFF 

  Aside from what SET said, about building the whole 2.2.25, if that’s 
the bug affecting you you may just apply a patch over 2.2.24 and build it.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [arch-general] Thunderbird 78

[mpan]

Thunderbird asks me to migrate my keys, and I am not
sure, if I should not wait a few more days.
  Whatever you choose, a warning: set a strong master password for 
Thunderbird before doing the migration. Otherwise Thunderbird stores 
your private key unencrypted and there is no warning about the situation 
during migration.⁽¹⁾


⁽¹⁾ https://bugzilla.mozilla.org/show_bug.cgi?id=1662272


OpenPGP_signature
Description: OpenPGP digital signature

Re: [arch-general] pam_faillock -- can we just remove it from /etc/pam.d/login?

[mpan]

On 9/12/20 5:41 AM, David C. Rankin wrote:
> Following the [arch-dev-public] Pam lockout thread,
> 
>   Can we just remove the faillock entries from /etc/pam.d/login without
> breaking anything if we don't need it at all (like for home computers, etc..)
> (…)
Not elegant, but moves faillock out of the way:

  deny = 999
  unlock_time = 1

Of course removing faillock completely would be nicer.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Thunderbird 78

[mpan]

> Is it possible to update it in [testing] at least?
  This version is not an “upgradeable” release, as stated by the
upstream. Not considered “next version” in the upgrades sequence. The
next version after 68.11 is 78.2, which is not released yet.

  Hypothetically [testing] could provide that release, but what for? To
produce bug reports that will need to be dismissed immediately, because
people didn’t suspected the upgrade is expected to break their
installations?

  What is the reason to install 78.0 or 78.1? Unless either:
 - You are interested in very early previews, in which case you probably
   should be on nightly anyway;
 - You are among the people affected by the CVEs present in 68.11?

  But if you have a reason, you can install the official Mozzila’s
release. There even is a ready PKGBUILD posted by someone on AUR, so you
do not need to write your own from scratch:
 https://aur.archlinux.org/packages/thunderbird-bin/

  A side note: I am not simply dismissive. Initially I was considering
that putting it in [testing] may be a good idea. But after some talking
with people around I changed my opinion.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Thunderbird 78

[mpan]

> Is there any reason the package is stuck to version 68?
  The reason is given on the very top of the page you have linked.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] What do you do with pacman.log? Periodically archive? Delete?

[mpan]

> This is more of what is the recommended practice ... for handling pacman.log?
  Mine is 10 years old, is 7MB. On a 1TB drive. Why would you ever want
to remove it? After 1000 years it will be 700MB, not even 0.1% of the drive.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] pacman system update - Why am I prompted to import a specific key?

[mpan]

>   On update today (yesterday's updates went fine), I am prompted to approve
> import of the following key a number of times: […]
> :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) […]
  Oh, “the heftig bug” ;). While Simon Wilper has provided the solution,
here is some background:

 “[…] I replaced it to get a clean break for a new key, which I'm
  treating more securely from the beginning (no secret keys on the
  laptop, just subkeys on a yubikey and the master key on a few
  backups)”  —heftig

-Syu often to avoid problems.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] oops, 'sudo: pacman: command not found'

[mpan]

> hi.  a month ago i ran out of room on my root file system, so relocated
> /var/cache/pacman to /home, and left behind a symlink. (…)
  “/var/cache/pacman” is owned by pacman and is supposed to be a
directory. If you have removed the directory and create a symlink
instead, the next update has simply overwritten it with proper contents.
Since it has been overwritten, it’s now an empty directory that contains
nothing and pacman can’t find “pacman-5.2.1.6-x86_64.pkg.tar.zst” there.
It seems that in the process you have deleted “/usr/bin/pacman” and,
because pacman can’t install things from non-existend archive, you are
also missing pacman now. Reinstall pacman using Arch ISO.

  As for moving the cache, it should be done using `CacheDir` in the
config, not through symlink. However, moving it to “/home” seems fishy.
Where exactly is it in “/home”? If your private home directory, you are
opening yourself to attacks. The cache should be in a location
accessible only to the root (or another user has sufficient privileges
to run `pacman` without further authentication).



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Multi-threaded mkinitpcio

[mpan]

> Actually this 2 minutes bothers me this much that I'm emailing Arch
> General Mailing List is because I'm afraid my Arch would be broken if my
> laptop shuts down in this process and I have to rescue it by live USB.
  For nearly a decade of using this particular Arch installation alone,
I never had a single case of losing power while mkinitcpio was running.
I wouldn’t be afraid of that scenario. And laptops are better than my PC
in that manner, because you have backup power from the battery.

> Does it help if it gets executed over multi threads or the bottleneck is
> somewhere else?
  For my particular setup, running `mkinitcpio -P` yields those times:

real1m8.320s
user0m24.742s
sys 0m12.806s

Half of the time mkinitcpio was waiting for disk I/O. Most likely
`find`, but that’s only mu guess.

  This is only a single computer. Unlike modern laptops it uses spinning
rust for storage, but OTOH it is also running a CPU that remembers 2000s
and DDR2-800 RAM. So both would affect the outcome.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Firefox "stalling" behaviour

[mpan]

> I'd really like to use the Firefox browser (currently using Iridium), but
> I'm seeing a strange behavior where it "stalls" intermittently. The
> rendering engine seems to randomly pause activity (i.e. not responsive to
> scrolling input), and these pauses can last for several seconds. It also
> appears to affect video playback.
> 
> I haven't knowingly done anything with my user settings that would cause
> this to happen; I have a few add-ons, but they should all be well-behaved
> (1PasswordX, Facebook Container, Multi-account Container, uBlock Origin).
> 
> Has anyone seen this and figured out a solution?
  First, check if those are not add-ons by running a clean profile. Mere
belief that they’re not the culprit is not evidence.

  If the behaviour continues in a clean profile, check load during those
stalls — e.g. in `htop`, which shows a nice load graph. Possibly
programs Firefox downloads and runs (aka JavaScript) are eating all your
CPU resources.

  If that doesn’t explain the problem, check if dmesg contains any
errors that correlate with your issue. That’s unlikely, but not impossible.

  Also see if you do have enough of RAM and no swapping occurs. That
shouldn’t be a concern on any modern computer, but the symptom is
similar and, since I have no specific ideas, everything’s worth checking.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Remove Clisp from repository

[mpan]

> I didn't know about this repository on GitLab, but if you go to the
> official Clisp site (https://www.gnu.org/software/clisp/), you will see
> that the latest version (2.49) was released on 2010-07-07.
  For clarification and providing a verifiable source: that SourceForge
page is ancient. The repository has been officially moved to GitLab over
a year ago.[1] And the SF repo was active until that time.[2]

[1] 
[2] 



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] How long do you make the passphrase for the private key?

[mpan]

> Randomly open a dictionary and then randomly pointing on a word,
> repeating this a few times, is one way for an artist to get an
> inspiration.
> 
> I wonder how safe it is to use such a method to generate a passphrase.
  An old Chinese proverb says: do not invent your own crypto.

  Diceware is much better crafted than you may imagine. It’s not just
some random idea someone had while contemplating life in a loo. It
solves some real problems and avoids pitfalls.

  What are the problems with the proposed method? First of all: what is
your RNG or CSPRNG? Is it your brain? Your hand? Then you have already
lost. If you’re just grabbing a book and opening it at a “random page”,
your generator is already biased. You have much greater chances of
picking a page closer to the middle than on the ends of the book. It may
be even worse when it comes to the selection of the word on a page. Are
you, instead, using an actual RNG or CSPRNG? Is it not biased? How are
you dealing with that issue? Are the values from it mutually independent?

  Even if you have a good [pseudo]randomness source, how do you map its
output to the page number and word number? It isn’t a trivial task and
if you do it wrong, you skew your distribution.

  A dictionary may contain long words. While you may imagine that is
good, because “longer is better”, it is giving you only a tiny
advantage, because the space a word takes is not really used. In English
it’s less than 3 bits per letter and it tends to be worse for longer
words. Still, no loss, yes? Wrong. Unfortunately many services limit the
length of the password you may use. It is also harder to get muscle
memory for typing long words.

  I believe a cryptographer could point out a few other mistakes as
well. The reason I explained this is not to inspire anyone to “fix” the
proposed algorithm. My goal is opposite: to discourage people from
undertaing such tasks. There is many gotachas, it is easy to introduce a
vulnerability and you don’t even get any testing/review for your method.
Better trust people, who spent half of their lives studying cryptography.

  How does Diceware deal with the above problems? It eliminates the
human factor. It uses a randomness source that for all practical
purposes is an actual RNG. A RNG that is even better than what is
typically used for private key genereation! The tiny bias it has is
acceptable, considering the great advantage of using dice. The set of
possible values is chosen in a way, which ensures no bias being
introduced while mapping from the output of the RNG to those values
(yes, it avoids the issue altogether). It is clear, transparent and
obvious at each stage — nothing up my sleeve. It can be used by anyone.
Finally, words are short, so the output is compact. After some time
entering such a passphrase is just a series of 4–5 taps on the keyboard.
APPRECIATE WHAT ARNOLD REINHOLD DID, because he did a truly good job. :)



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] How long do you make the passphrase for the private key?

[mpan]

> "IMO an averaged "strong" but still memorizable passphrase, even when
> following obsolet rules, is ok."
  But we do not need to follow any obsolete rules anymore.

> In a follow-up email unfortunately send after your reply, I exactly
> describe the apartment door scenario.
  Which I have indirectly answered before you have sent it. With the
second paragraph of my message. The comparison to the apartment door
can’t be extended further, because an important difference appears.
Better physical security costs a lot more and even now we’re sitting at
the edge of the dimishing returns abyss. That’s exactly the reason why
Yale decided to stop locks wars in 19th century and promoted pin tumbler
locks as good enough. But the analogy to the lock doesn’t extend well,
when it comes to information security. The costs have different nature
and, as it happens, right now everyone can employ good security at
approximately the same cost as the “not too horrible” solutions.

  You are trying to argue, that it is OK to use pin tumbler locks in
wooden doors, while everyone can — at nearly the same price — acquire
10-inch steel gates with scifi eye scanners and a private army to defend
the gate.⁽ᵗⁱⁿʸ ᵉˣᵃᵍᵍᵉʳᵃᵗⁱᵒⁿ⁾ ;)

  With Diceware, as an example, you randomly choose 5 words and have a
60-bit password. Why even bother with obsolete rules?



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] How long do you make the passphrase for the private key?

[mpan]

> Black hats are able to hack Google and Facebook, what ever you
> will do, you never ever will be able to reach the level of security
> those and the other most successful computer related companies are able
> to accomplish.
  In 2015 four men have stolen equivalent of 200M GBP from Hatton Garden
Safe Deposit. Does that mean you are not locking your door, because
“thieves can get in anyway”?

  The argument would make sense, if the better solution would be
considerably more expensive. But in 21th century it is not. Everyone can
get good security without effort. There is no need to artificially
decrease it.

  The topic is also about signing packages, that will be available to
others. There is much more at stake here than just Manuel Reimer’s
security and aiming for the best should be encouraged. Happily for us,
nowadays he can achieve that easily.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] How long do you make the passphrase for the private key?

[mpan]

  tl;dr: follow standard practices — there is nothing special about
passwords for private keys.

> I want to publish a package repository with some packages that I need
> and only want to build once for all my systems.
> 
> I want to make the packages available for general use. I have server
> space for that so I only have to rsync my final repo to my server after
> compiling my packages.
> 
> I have my autobuild set up and signing seems to work, too.
> 
> For convenience, I decided to make the passphrase not too long.
  This alone makes me raise an eyebrow and wonder, if the security is
already compromised.

> I have 10 characters with both, alphanumeric and "special characters".
  Is it coming from a proper CSPRNG or an unbiased random source?

  If not — in particular if was your brain that generated it, you have
applied any changes to „make it easier to remember” or chosen one from a
set of random passwords — you are close to having no password at all.
But if it properly generated, it is meeting the often repeated password
criteria: 8 characters in the past, becoming 10 nowadays.

  But that doesn’t mean it is fine. Random, compact passwords are hard
to remember. Unless you’re using a password manager, you’re going to
either make mistakes (like writing down the password) or you’ll undetake
an unneccessary effort for little gain (remembering it). There are
better ways. See diceware and friends: it lets you generate a password
with very good entropy, but being easy to remember.

  If you’re using a password manager, you should not care about the
password being “too long”. After all it’s not you who type it. Go for 16
or 20 random chars.

> I think if the passphrase is meant to be uncrackable alone, then we
> wouldn't need the big private key file, right?
  Those topics are unrelated. The password is only used to protect the
key in case of a leak and plays no role in security based on that key.
If the key is breakable, whether it is protected by a strong or weak
pasword, or not protected at all is insignificant. The attack will not
even consider the password.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] package contents on fresh Arch install, like python etc...

[mpan]

> A day back, i made a fresh install of Arch on my desktop. It is completely
> fresh as like it doesnt even have an account other than root.
> My doubt is, wont basic tools like python come in Arch install? or do we
> have to install by ourselves?
  You are the administrator. You are choosing what you want to be
installed. The base group contains only the basic tools and their
dependencies.

> also can anyone give me a brief approximate list of packages that will come
> pre-installed in Arch, other than gnu tools?
  pacman -Sg base



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] License for libdrm packages

[mpan]

> I have read that article in ArchWiki. I understand that point that MIT 
> licences are all custom because of individual copyright line. But then I do 
> not understand when should I use license=('MIT') instead of 
> license=('custom')?
> I have read that MIT is a set of licenses, but it is kinda unclear. I guess 
> that if there is clear text that it is a MIT license, then I use MIT, 
> otherwise for MIT-style licence I just use custom. Am I correct?
  I talked about the topic on #archlinux and it seems that the accepted
solution is to use 'MIT' in the `license` array, despite there is no
corresponding text in the “licenses” package, and put the text into
“/usr/share/licenses/pkgname”, despite it is not marked as 'custom' in
the `license` array. ¯\_(ツ)_/¯

  I still consider it illogical, but I have been outvoted. But I would
not claim that “libdrm” maintainer is wrong on using 'custom' here.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] License for libdrm packages

[mpan]

> Hello. I was repacking amdgpu-pro deb files and when I started converting 
> licences, I have noticed that libdrm* packages have a MIT Licence text in 
> copyright file. I decided to check if AUR/libdrm-git and Extra/libdrm uses 
> MIT licence, but they don't. I contacted Lone_Wolf (maintainer of libdrm-git) 
> and he said that he used a licence from Extra/libdrm.
> Should not it be changed to MIT instead of custom?
  “MIT-style license” is a class of licenses, not a specific one. Each
software using MIT-style licensing is having its own, independent
license text. While in practice they may be nearly identical (modulo
copyright line), they’re in fact separate licenses. The topic is
discussed on the wiki:
.

In particular the terms include:
 --
  The above copyright notice and this permission notice (including the
  next paragraph) shall be included in all copies or substantial
  portions of the Software.
 --
Which means that if multiple MIT-licensed pieces of software are
combined, the complete notice of each of them has to be included in the
final work. And this is exactly what happens in case of libdrm:
.




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] pacman.log has no timezone information in timestamp

[mpan]

> I just used the /var/log/pacman.log for the first time to give me the
> last date-time I did a system upgrade ('starting full system upgrade' in
> the log). There is no time-zone info in the time-stamp. It's also not
> UTC. Does anyone know if this is by design or a bug?
  `pacman` uses local time of your system. Indeed it seems like an ommision.

  You may consider opening a feature request, so pacman.conf would allow
either an option to include TZ in the logs (good idea) or setting custom
time format (worse idea, as this would bind `pacman` codebase to the
specific time formatting function).



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Suspicious activity and slowness ...

[mpan]

> since some days, I'm noticing HD is too busy, and my laptop is very slow
> in some cases.
> 
> Are there any invisible background threads running? How can I find out
> about those? Running top, cpu use should be only about 30%, so it should
> wait for tasks to be executed, instead.
  iotop should show which processes cause I/O.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Add MIT Licence to /usr/share/licences/common

[mpan]

>>> It states MIT/BSD are special cases, just out of curiousity, what makes 
>>> them special that they cannot be added?  
>>   Because there is no MIT or 1/2/3-clause BSD license. There are
>> hundreds of independent, barely related licenses that are quite similar
>> and, therefore, are considered together as a class of MIT licens*es*
>> (note the plural), 1/2/3-clause BSD licens*es* etc. Despite many of them
>> may be very similar and, in fact, usually they share huge portion of the
>> text, they are formally different agreements.
>>
>>   In the above explanation I do not support any of the sides. Whether
>> classes that share 100% of important content and 99% of formatting
>> content, should be considered similar enough to have a shared entry in
>> Arch’s licenses directory, is a separate decision. I am just explaining.
> 
> It has nothing to do with any of that. It's simply that those licenses have
> project-specific copyright information added to them and cannot be generic.
  Approximately the same as what I’ve just said, but less
verbose/precise. :)




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Add MIT Licence to /usr/share/licences/common

[mpan]

> It states MIT/BSD are special cases, just out of curiousity, what makes them 
> special that they cannot be added?
  Because there is no MIT or 1/2/3-clause BSD license. There are
hundreds of independent, barely related licenses that are quite similar
and, therefore, are considered together as a class of MIT licens*es*
(note the plural), 1/2/3-clause BSD licens*es* etc. Despite many of them
may be very similar and, in fact, usually they share huge portion of the
text, they are formally different agreements.

  In the above explanation I do not support any of the sides. Whether
classes that share 100% of important content and 99% of formatting
content, should be considered similar enough to have a shared entry in
Arch’s licenses directory, is a separate decision. I am just explaining.






signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Setting make options for aur-packages

[mpan]

> (…) My goal is to build using multiple jobs (-j option for make).
  Consider -l instead of -j, with -j being used only to limit the number
of subprocesses -l could spawn. For example:

  make -l 4 -j 100 …

This will ensure make’s load is approximately 4. The additional `-j
some_bigger_number` is required to avoid creating excessive number of
subprocesses.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] 'gcc' vs 'c++' for compiling c++ files

[mpan]

  While Patrick is right and I agree that you should use the proper
compiler for the given language, it is not true that your assumption
about filenames was wrong.

  The `gcc` command is choosing the compiler for the file based on its
suffix¹. Files ending with “.cc” are among these considered to be C++
sources and they should compile fine with `gcc`.

  Your description confirms that compilation goes ok. What doesn’t is
linking. Compiled files have no language — they’re already compiled —
and therefore `gcc` has no idea that it should do language-specific
magic, like linking against libstdc++.

¹ man gcc → the begining of “Options Controlling the Kind of Output”




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] pacman doesn't show download progress

[mpan]

>> Notice how the Content-Length: header is missing.
> Thanks for the clear explanations, at least I understand what's happening, 
> it's up to remote to fix.
  Don’t write them to fix that, as nothing is broken: Content-Length is
not required.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Depends on foo-bar=10.0-3

[mpan]

>>> why does a package from official repositories mentions what version
>>> of a dependency is required?   
>> Because it may be that it is working only with that particular
>> version.
> That doesn't explain why it is needed or in any way useful for a package
> provided by official Arch repositories? Partial upgrades are
> unsupported [1]. Actually it could be vary annoying, if packages now
> start including the version of a dependency. I didn't notice that
> packages mention dependency versions for at least the last 4 years [2].
> It's not the only dummy package I'm using for at least that long.   No one 
> said people are allowed to install only packages from official
repos. You have yourself delivered an example of a package that had
pulseaudio listed in its provides entry.

  Another case: sometimes multiple packages in the official repo may
deliver the same thing: see jre8-openjdk and jre7-openjdk — different
versions of the java-runtime. Or mysql (*now* no longer in official
repos) and mariadb: different implemenations of the same flavour of RDBMS.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Depends on foo-bar=10.0-3

[mpan]

> why does a package from official repositories mentions what version of
> a dependency is required? 
  Because it may be that it is working only with that particular
version. The two common scenarios are:

  1) The package requires protocol/API/ABI/header/etc-level
 compatibility. You may see this like: foo=a.b.c and bar=a.b.c
 are coming together.
  2) The package requires newer API (≥X), but it is also known
 that available versions newer than X have some bug that
 prevent the package from working (≤X). Effectively one
 gets =X in requirements.

  It seems that you case is the first one.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Procedure for getting informed about ban duration and reason

[mpan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

  The issue is solve now: one should contact another op (not the one
responsible for the ban).

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEERGuTZCqWmv5+0VD7fISBmK6T07sFAll5NRkACgkQfISBmK6T
07uSRAf/USHM81Uc+i9JV5WItjOSqE4ZpCj0UiETCRYMPF0M0R3NjsMFQkSzXBou
ePYi0GB4b2v9uLb9b/vA0y0RCQ62The59H6EJExGfqeukATaOtfatp4Jas2uBtXs
O6DfrdkyJio8Fre6FOkaszX1SaHIH7V7kBwXeWIrEvsd+1eq3lbR2m0NYC6OpcJE
nlvMd0OW6Lmnc0LHcdFXozdwIAkzea5b/U6fh5dir1TLfz/8z8I0U0huzxuMpmkJ
CLrVV63KAq9XpKCjOkJ3y9dY2nmhD0epazzJzcNSI9JsQr+RQDpDrkhZVrNfeqk+
Yeuo4cBtBO2sRvh2zNE6rhaw6N3QKg==
=a0kQ
-END PGP SIGNATURE-

[arch-general] Procedure for getting informed about ban duration and reason

[mpan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

  I’m asking for an advice on how to proceed. I am *not* discussing
the reasons or trying to rant.

  The situation is:
   — On July 25th at 3:10 UTC I have been banned on #archlinux-offtopic
 with the reason „fuck you” and a warning „next time you trash talk
 on the ops, I set it to a week”. I was sleeping at the time, so
 I have discovered that just before 16 UTC.
   — Since I was given no info on the ban duration and the reason seemed
 strange, I’ve wanted to contact the op responsible for the ban. He
 was absent, so I was advised to use phrik’s !later to send
 a message. This is what I have done, asking for the reason and
 the relevant logs with the context.
   — The op has appeared. After waiting for a hour I’ve received
 no response, so I have PM’d him with the same question.
   — After another hour of waiting there was still no answer, but seeing
 the op on #archlinux I’ve asked him about the issue. I was informed
 that if I am going to ask about that, the ban will be prolonged and
 then I was threatened with a “final warning”.

  It’s July 27th ~22:30 UTC and I am neither unbanned, have no
information on ban duration or the actual reason and being prohibited
from querying that via IRC. What should I do next?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEERGuTZCqWmv5+0VD7fISBmK6T07sFAll5F5YACgkQfISBmK6T
07tbAQgAowUzUloVRgw2umrYTEVcJ6cBZ0OG17PwR/3D2kXoIn1p1Ke0zA9KVVLY
dxjY3DwdMso+gVS3vCoBsOOGvxKGbXldE7fX8u8EAiPNvPNZt33JLvb1i9jFFaEG
5ArpV8dOc1rAaARkmAyzJOCnUjqZH4GfVZmLzEbX1GwdIm4L55JZyN63fM6asrTu
/KaoI+oBZ1WhoKtBOQqCH3Ivqbpq5u5ZH8TdiQwmxviujhQEo1SqQ9yX+rGV8CGA
D/bDIwhkk7FKSB2RBlbKOpW+3CLPSKa8ad6tFEOHWpt5joRTwdxnF2/ZhC8MNBfZ
Z7LUYjaervciKhZFCsUIQ4GCCN2owA==
=uo7i
-END PGP SIGNATURE-