HCL Suggestions?

[Gaiko Kyofusho]

First, these are just a few suggestions, I really appreciate the HCL as it helped me select a very functional computer that worked with Qubes "out of the box".

Despite the HCL being helpful I wonder if it possible to add some additional functionality to it? "That One Privacy Site" has a very useful table that can be sorted in a variety of ways, something like this for the HCL would really be useful. Also It seems people have asked fairly often about ideal notebooks and asked about memory, weight, age (year released?) etc Adding a field for these things (mem tested with, and max mem) could be quite useful for those wanting for find say the lightest notebook that is working with 3.2 (for example).

These are just thoughts, but as I am hoping to get another computer in the next year or so I tend to refer to the HCL to see if its been updated and compare computers etc.

Just my two cents.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-02-03 15:37, Gaiko Kyofusho wrote:
> First, these are just a few suggestions, I really appreciate the
> HCL as it helped me select a very functional computer that worked
> with Qubes "out of the box".
>
> Despite the HCL being helpful I wonder if it possible to add some
> additional functionality to it? "That One Privacy Site" has a very
> useful table that can be sorted in a variety of ways, something
> like this for the HCL would really be useful. Also It seems people
> have asked fairly often about ideal notebooks and asked about
> memory, weight, age (year released?) etc Adding a field for these
> things (mem tested with, and max mem) could be quite useful for
> those wanting for find say the lightest notebook that is working
> with 3.2 (for example).
>

Indeed, these would be useful. Unfortunately, though, we can't even
keep the existing HCL up to date (see below), so any new features
would have to come from the community. Would you be willing to submit
patches for these?

> These are just thoughts, but as I am hoping to get another computer
> in the next year or so I tend to refer to the HCL to see if its
> been updated and compare computers etc.
>
> Just my two cents.
>

This is a good time to mention that we're in need of an HCL
maintainer. Our longtime volunteer HCL maintainer, Zrubi, no longer
has the time to do it. We all owe Zrubi a debt of gratitude for
keeping up this thankless task for so long! :)

Any volunteers?

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYlTMPAAoJENtN07w5UDAwy8IQAIsstiJxRm1/c8ZSqo86jS9x
zHiO84jZKiyvXUcxhLKFxrL0E3N8tt88cqxt4WKJaNG08WoHfYAf+HrikxUBgVhm
8ofofs4hMFQzMCwnaYYN4wh4ziKoNZ4m0+EJfOmXqLMeetXA5EgBPNmLCHanowHZ
fpFteU9eM3S1xuvtrsD/tcFFvANosIIPmh7x1slDMX13HOXiFRROoMMJd1uFwdmr
sIxpwlv738p8jNF2vLhh2xVLJLir1ZX6ovZNwLpfb6T6MzGH801sEgNujzDRDrRy
vpn2oee7X8N7Ww0QAknwYPZtWdbxGLB/Zjygcvv9ZHsA/PI86c31F01Jcfs4s+iK
7vUZu0uGb368KrGkMaDWvLPgXpQLBl/eRcVedJvdaUhdhwOpx4FPBWD78lbAtAkk
JQj65g6PrXTvaSXzt05r6Y4FDYnzYIrGMH3hxfctUGhJzASBsAVgK892CvgycBfu
YMrYneEDVAd34/zFK1DS5Lk8jSwit6W089KpN6qPclpsgAEqDU60oi9CKmU/GTBf
71hOwX3gn8a5PBCmI8ZbUebdrorO1gmanJRmL7tnDZFbeD2cs5+E3aE31DgkauAr
VaWuuod2Xsx++P7CMmvOjhcJ10oLIS/fSFdNGLVVEvJ9xLp5HlH6rZwliAq/xgCs
EDv+Qt6gmrKDbJvo3/BI
=iGK8
-----END PGP SIGNATURE-----

[Oleg Artemiev]

> This is a good time to mention that we're in need of an HCL
> maintainer. Our longtime volunteer HCL maintainer, Zrubi, no longer
> has the time to do it. We all owe Zrubi a debt of gratitude for
> keeping up this thankless task for so long! :)
>
> Any volunteers?

Why not to just script-out this once and forget?

source information: email from someone, output information -> some
file to put on the web?

--
Bye.Olli.
gpg --search-keys grey_olli , use key w/ fingerprint below:
Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E
Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-02-04 15:10, Oleg Artemiev wrote:
>> This is a good time to mention that we're in need of an HCL
>> maintainer. Our longtime volunteer HCL maintainer, Zrubi, no
>> longer has the time to do it. We all owe Zrubi a debt of
>> gratitude for keeping up this thankless task for so long! :)
>>
>> Any volunteers?
> Why not to just script-out this once and forget?
>
> source information: email from someone, output information -> some
> file to put on the web?
>

Some stuff still had to be edited manually, but it could indeed be
automated better. Can you help us with that? :D

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYlxzlAAoJENtN07w5UDAwK8AQAMRo/7/9OUj0W6/CTc32Bqfj
iQ6IfX24RMKDSs8GGhFQpSeBX7O6O8+kKMSQEpoOAbLC9BL/u1amlC90N0Eb1DcZ
GcU6ZtG7p63WlyqO3ADrBP6XKzrxyXV6v800inAKc7eVTGr3CFkvcc81+l/jT5kZ
tDXHjzNMn+VXQfvo/b3IUJcq+l0N5lYd0PPOC4hFEW8kzIBcPxH9YO1ZOw2NrgPp
xlunMLyhWAmYn8I/9QucTveD11szzs//Meq/JvbETYZDYGRPZqdh5C9imEkJtHVw
jwJnaD/mX2CvzkBV+HG3XQYDa8ZdQInE2bPt1krDu0pt8KSKkgO4aj1sj/AauR1y
AgWHovX4sC40PkvkTh8WyjZY8aJ7ynxmdXGRAzvbrKoTIN8YQN2mCbzZzHfd2hFa
8RVG7Rud0OX1BjIKI5XACMV+U0RI85/mb+2NwfXjqW77BwAL5wih4PW4oa1bHgtj
63gElFEdzvYHdmsIUTdCjnQ5tgB02uWYYi0uAHdyG8DwuFr13i+U4fj/prNP8l5l
NrAdyb14jDMqb9tF1iFYzFpxVfH9umLbzWpXNpu4n+vq65+flN2IvYwvqKhoS7B3
YzCN09xRSKKR7f2/NyOHgKl1pScVVriqI6kYNb9iGIv8b1n+0xiigCrYPRATmEL9
vwoloQWohop56Xwbh3u7
=UVVr
-----END PGP SIGNATURE-----

[Stickstoff]

On 02/05/2017 01:39 PM, Andrew David Wong wrote:
> On 2017-02-04 15:10, Oleg Artemiev wrote:
>>> This is a good time to mention that we're in need of an HCL

>>> maintainer. [..] Any volunteers?

>> Why not to just script-out this once and forget?

I can't help with maintaining the HCL, sorry. Yes, an automated solution
might help here.

Talking about automation: I am in a position to have several notebooks
on my desk every week. Anything between three and ten maybe, steadily.
Mostly older consumer devices.
How much of a priority is it to fill the HCL? If I had a bootable stick
which fetches all interesting info in short time without (much) user
input, I could do that to a lot of notebooks.
This would only make sense if we could find out the notebook model with
the script. Or maybe just type it in while it scans stuff.

There are many places with high notebook throughput. Heck, we can even
walk through an electronic store and check out one new notebook after
another, if it's reasonably fast and simple.

Would it be worthwile to have many new HCL reports to program such a
stick? Is an automated report even worth much, without hands-on
experience of a user testing functionality?
I am no programmer, unfortunately, so I can't create such a stick by myself.
And, of course, we need to be prepared for many new reports with a new
maintainer and/or a more automated processing.

Stickstoff

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-02-05 05:10, Stickstoff wrote:
> On 02/05/2017 01:39 PM, Andrew David Wong wrote:
>> On 2017-02-04 15:10, Oleg Artemiev wrote:
>>>> This is a good time to mention that we're in need of an HCL
>>>> maintainer. [..] Any volunteers?
>>> Why not to just script-out this once and forget?
>
> I can't help with maintaining the HCL, sorry. Yes, an automated
> solution might help here.
>
> Talking about automation: I am in a position to have several
> notebooks on my desk every week. Anything between three and ten
> maybe, steadily. Mostly older consumer devices. How much of a
> priority is it to fill the HCL? If I had a bootable stick which
> fetches all interesting info in short time without (much) user
> input, I could do that to a lot of notebooks.

Thank you for you willingness to do this! It might be enough just to
install Qubes onto a USB drive, boot from it, and run qubes-hcl-report.

> This would only make sense if we could find out the notebook model
> with the script. Or maybe just type it in while it scans stuff.
>

I think qubes-hcl-report automatically gets the model number in most
cases.

> There are many places with high notebook throughput. Heck, we can
> even walk through an electronic store and check out one new
> notebook after another, if it's reasonably fast and simple.
>
> Would it be worthwile to have many new HCL reports to program such
> a stick? Is an automated report even worth much, without hands-on
> experience of a user testing functionality? I am no programmer,
> unfortunately, so I can't create such a stick by myself. And, of
> course, we need to be prepared for many new reports with a new
> maintainer and/or a more automated processing.
>

Good question. I think the reports would still be somewhat useful,
since at least anyone who is considering acquiring model X will be
able to see the HCL report for model X before acquiring it. However,
HCL reports for newer models are likely to be more useful than ones
for older models, unless the older models are particularly popular for
some reason.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYlzloAAoJENtN07w5UDAwHX4QAIUH183kbpYz/m4oK9Bl4w96
lpI18e+cS8nI6jirkX4Zkw/PNtj8F4eME3mE1dSapcUlo2h5IuBdJ4BgZvB7hK4D
6f08GuWJxQ5TJJCzM/k/YlYQD4KX+yQKsz5GLQ2vfFpFFec6UzA21r2Dkqs4nm9q
TKEFvDzfgg6xcqOQRkAz3rfPvW3oF+/zDuPocb267EyXGkkc/rEoWAjrFWIxr2VX
0WMA2hIwIBLSpPsYAQayVBz2AcyWhAj5fvdDFaXlTzS8s6hJMYzz5hyf7lylYlHr
YXEh/FU6BEqpegYIzYKom2Z25Vaigoal1UXNJdrrKNhOEi/dl7Xf6BFN/HCr5Rqh
k4wrSKJwISBfXXPLW4xziUgJvTPg/3Sn+UdEo1qDjmUtwip0sttgHJYoH/CjsZ7x
9QjFMUiOlwh6/kpWnZLU9n1hOAdxvnF2FYei2oV+z/MNM6FtJFyOBlmmVeFsaXGc
L7OkWBpUvj7vuBlhlaFh5My//GOwl0SQiwQxZMCyMqwn5maxZOGjabGlCXkPzNde
RwwrueHxnAJpLNkwTLzeiciJlKJtwcJcvOsImftVZLLWJ/Es3sz7wMjwcdo/A5UP
xKy7b9A52OvpvdWP65lB+DL/ojnJ+M6XtIHcjTrkX5QGBQ/VgF+gFGt/ziw9ey39
en81m8Yz07vmNfaZLSU6
=xZ5r
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-02-03 17:49, Andrew David Wong wrote:
> [...] This is a good time to mention that we're in need of an HCL

> maintainer. Our longtime volunteer HCL maintainer, Zrubi, no
> longer has the time to do it. We all owe Zrubi a debt of gratitude
> for keeping up this thankless task for so long! :)
>
> Any volunteers?
>

Thank you to everyone who volunteered! Our new HCL maintainer will be
Chris Laprise (tasket), who has been a very helpful member of the
community for many years!

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYmIJoAAoJENtN07w5UDAwND0P/iK6TFIiuKLu6vx3n7F+2sie
nx9pYeQamarq6eZn/v294S9w6waQI5F6aCnxziEMiPU+h8tr2IKFaWvYolW50JR6
nbwkILRd9eDPSekHHpTUta38FhnASwTnBSXuXHfvk0J3hbHsGwYs0GxMD7q0O/EH
ZabhMyTAKPzVk1Jagv6cgkOrj7Ai4HpwMqdHEX59D420oAiyvjSFBLfcr3gGbL4v
aQBpRruT7xsTdU3DOUi6Fp8NcIOmV/JcrrAgNkb1aOkU6jgkCjNzJN7hCJlU7cWN
St9uwgCy0sEHIaPuGJRrxgCWQaC6x73S8BWJgwshY7/D8nOYuL2YmOyTwisWW4HH
26dliKbCPCLtvj2GbM2AAU7mCbBh6D8tSzGkPZVUDfpMW507ILSgxr6sQAqu5VsZ
Km3JwZV0Na89bq9/IQORWk61OQC2KR9etPEPjgohj4b/A/6ZxOYLzy/66qHbcBab
RcU9/z/dialyAwDo5GJparC4rsJtNijKVKjQJwXeLOVacu3nBFRKD44bYPK4s9ZJ
rEKNFN0YuH7TIWCP449E/EnLJKlVI80/k+KJW06VpGh/HuEPO1HGuVeQGrZuUL8C
zuP5s0RpSa1TGTuInhXKzZw39/vmKFTtLUgr4uYKyM6LDut/u8cvfTFiZbQ9rrcs
jGSmM2vM7tInTh3vsytt
=VhMu
-----END PGP SIGNATURE-----

[Oleg Artemiev]

On Sun, Feb 5, 2017 at 3:39 PM, Andrew David Wong <a...@qubes-os.org> wrote:
> On 2017-02-04 15:10, Oleg Artemiev wrote:
>>> This is a good time to mention that we're in need of an HCL
>>> maintainer. Our longtime volunteer HCL maintainer, Zrubi, no
>>> longer has the time to do it. We all owe Zrubi a debt of
>>> gratitude for keeping up this thankless task for so long! :)
>>> Any volunteers?
>> Why not to just script-out this once and forget?
>>
>> source information: email from someone, output information -> some
>> file to put on the web?
> Some stuff still had to be edited manually, but it could indeed be
> automated better. Can you help us with that? :D

I'm interested in helping automate this. Though can't claim that it
will be fast.

Could you, please, point me into what is already automated (repo +
path) and related brief dox on how
execution is done currently (if any)?

My idea how it should look like:

a special qubes image:

*. preinstalled on some usb stick
*. has only a preconfigured VMs: netVM, firefwallVM, user interface is
not required.

Dom0 has a script in startup scripts that:
*. runs HCL
*. updates HCL file: old data copied somewhere inside dom0 for user reference
*. copies file to net VM,

VM has a script:
*. checks for HCL file to be present eache minute
*. checks that internet is available
*. makes a gui request to a user to fill required manual fields (model
as the store names it, user name(optional), and so on)
*. once confirned - sends HCL file to specially assigned emaili at qubes.org

Qubes web:
*. A sctipt on qubes.org updates some HCL html in predefined format

PS: I would prefer just a single HCL usb stick run, that boots, asks
user for input 'seller named model as' and mail result automatically
(now or later if at runtime we had no internet) -
no user interface except this, GUI is optional, all Dom0/VM made in a
single place in modified Dom0, but that is against architecture and
making such an image may require much more
work than scripting this as a chain of small scripts + preconfigured
VMs. BTW: I'd like such an thing also for old versions of Qubes OS -
sooner or later we will face usual store that some
hardware is okay w/ old Qubes but too slow with new.
Alternatively we could have a special preconfigured VM image that does
all VM part above, but require user filling HCL to activate manually.

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/07/2017 10:29 AM, Oleg Artemiev wrote:

> Could you, please, point me into what is already automated (repo +
> path) and related brief dox on how execution is done currently (if
> any)?
>
> My idea how it should look like:
>
> a special qubes image:
>
> *. preinstalled on some usb stick *. has only a preconfigured VMs:
> netVM, firefwallVM, user interface is not required.

Qubes Live USB should do the job - but AFAIK that project is stalled.

> Dom0 has a script in startup scripts that: *. runs HCL *. updates
> HCL file: old data copied somewhere inside dom0 for user reference
> *. copies file to net VM,

These are handled/done by the hcl script itself.

> VM has a script: *. checks for HCL file to be present eache
> minute *. checks that internet is available *. makes a gui request
> to a user to fill required manual fields (model as the store names
> it, user name(optional), and so on) *. once confirned - sends HCL
> file to specially assigned emaili at qubes.org

What we are need from the user is his/her actual experience. All the
info collected by the hcl script are just pure hardware data. Without
user experience it is useless.

> Qubes web: *. A sctipt on qubes.org updates some HCL html in
> predefined format

Here is the current workflow as i did it before:
https://groups.google.com/d/msg/qubes-users/RagFsGlhPTY/HXyRCQOUBQAJ

See that old thread for more ideas about a better HCL reporting.



- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYmZicAAoJEH7adOMCkunm19UP/3fNRVfJGnL30LZvY8FD4wou
nflRzK69UClxKagCA9E8tIJnjy/qOn2GjCd71pOwuHjEUXjha8ceSYPq8SVtO6zi
R7bvnRxs0nqDV0/QuIgUJiB5jFlL5g8xJzrM97KKUGzUnjBp4ch9INIo0/6xVOlm
n+ElMa4LsOrf+AljMNq7XiEax5rxEvH/dAqxjcLyKMuZ2ei75hMyfL/unn8BhwHF
WxrElylZa0ZiLhAOLY735JD3MW+1UHjcEeEsgyhMlSfHLtFK+GdkTnc02bWenpQ3
m8m4lcG9uioutrEsNYIgKkqWqsGNrqNkFr2P4q4VSW7+sqca6vr8fFE8E3qLO0eF
0O9jw6xv3vuEg5t8AGwTeFOmbxuMlj8RbYtvugjHOpqN6nf4k8OjNF/tUk5RNDDk
PLyDqC4H9mHev1PFrZTNYf9IYGk+ldCXynxZ8jZjF9cSEQM2FXqfGJRipTgoo2Nj
cVLHq8pghzte6+dwmYz+oNQcyjRPNGW+97+SiXJEoOXnpAq02JJf4Mavndcs81xr
/VmwgcToVMAI0xz0FseeTaQ0mLkC4OfL/e7c265CI3XKeCGFy5ORqsq7yOTZ6Hzx
kmJG1Oo8yT9+hcd8QGdGjhp9IUVkeDZbUyUt33w0iMXaREXn9Fc4TCt2NJAAhydT
Xv6VsNsFoipnYbOANrVp
=4WAz
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

I started an effort to automate HCL updating a few months ago and
thought I'd pass on my notes in case anyone finds them useful.

First, you'll probably want a complete and incrementally-updateable
local mailing list archive. The most reliable way I've found to dump
google groups is with [1] (amusingly implemented in bash).

To decode the mails to extract the HCL files, I tried to use ripmime
[2], but hit cases in our archives that crashed it [3]. I got
sidetracked trying to produce a minimal case reproducing the crash and
determine if it was exploitable, but other priorities took over.

The crashing cases in our archives included the following (which are not HCLs):
- https://groups.google.com/forum/#!msg/qubes-users/8n9i1GiIl7s/jvIkXCiV0awJ
- https://groups.google.com/forum/#!msg/qubes-users/h_5wX9IN-MI/XRlekv-GcU4J
- https://groups.google.com/forum/#!msg/qubes-users/jr8BWxhmQq4/KteMXP5nxd8J
- https://groups.google.com/forum/#!msg/qubes-users/v739hab0FDo/Yru2TDVAEX8J

Reported upstream, but maybe you want to use a different mime-decoder
regardless.

[1]: https://github.com/icy/google-group-crawler
[2]: http://www.pldaniels.com/ripmime/
[3]: https://gist.githubusercontent.com/anonymous/239a136df2479d36f085e075ddc52287/raw/d6a2fb64ce9e64a8fa1de2962f8bc447e395d14e/ripmime-crash.txt

[Oleg Artemiev]

On Tue, Feb 7, 2017 at 12:51 PM, Zrubi <ma...@zrubi.hu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/07/2017 10:29 AM, Oleg Artemiev wrote:
>
>> Could you, please, point me into what is already automated (repo +
>> path) and related brief dox on how execution is done currently (if
>> any)?
>>
>> My idea how it should look like:
>> a special qubes image:
>> *. preinstalled on some usb stick *. has only a preconfigured VMs:
>> netVM, firefwallVM, user interface is not required.
> Qubes Live USB should do the job - but AFAIK that project is stalled.

(

>> Dom0 has a script in startup scripts that: *. runs HCL *. updates
>> HCL file: old data copied somewhere inside dom0 for user reference
>> *. copies file to net VM,
> These are handled/done by the hcl script itself.

nice

>> VM has a script: *. checks for HCL file to be present eache
>> minute *. checks that internet is available *. makes a gui request
>> to a user to fill required manual fields (model as the store names
>> it, user name(optional), and so on) *. once confirned - sends HCL
>> file to specially assigned emaili at qubes.org
>
> What we are need from the user is his/her actual experience. All the
> info collected by the hcl script are just pure hardware data. Without
> user experience it is useless.

Some data are 'pure hardware data' but very important (i.e. some sort of
restrictions) are possible only w/ specific CPU features - I'd never buy or
recommend a laptop that is able to run Qubes but has no full support for
all Qubes features. Having a tool to get this information right at the seller
store should be nice .

>> Qubes web: *. A sctipt on qubes.org updates some HCL html in
>> predefined format
> Here is the current workflow as i did it before:
> https://groups.google.com/d/msg/qubes-users/RagFsGlhPTY/HXyRCQOUBQAJ
>
> See that old thread for more ideas about a better HCL reporting.

Thank you, 'll look.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Feb 06, 2017 at 01:46:59PM -0500, Jean-Philippe Ouellet wrote:
> I started an effort to automate HCL updating a few months ago and
> thought I'd pass on my notes in case anyone finds them useful.
>
> First, you'll probably want a complete and incrementally-updateable
> local mailing list archive. The most reliable way I've found to dump
> google groups is with [1] (amusingly implemented in bash).
>
> To decode the mails to extract the HCL files, I tried to use ripmime
> [2], but hit cases in our archives that crashed it [3]. I got
> sidetracked trying to produce a minimal case reproducing the crash and
> determine if it was exploitable, but other priorities took over.

If using mutt, it should be also not so hard to write a macro for this.
But it wont be pretty.
Generally it's a good idea to automate it somehow. Filling some fields
(works/doesn't work etc) still needs to be manual, but for example link
to the message could be extracted automatically.

> The crashing cases in our archives included the following (which are not HCLs):
> - https://groups.google.com/forum/#!msg/qubes-users/8n9i1GiIl7s/jvIkXCiV0awJ
> - https://groups.google.com/forum/#!msg/qubes-users/h_5wX9IN-MI/XRlekv-GcU4J
> - https://groups.google.com/forum/#!msg/qubes-users/jr8BWxhmQq4/KteMXP5nxd8J
> - https://groups.google.com/forum/#!msg/qubes-users/v739hab0FDo/Yru2TDVAEX8J

This could be avoided by filtering first on "HCL" keyword in the
subject.

> Reported upstream, but maybe you want to use a different mime-decoder
> regardless.
>
> [1]: https://github.com/icy/google-group-crawler
> [2]: http://www.pldaniels.com/ripmime/
> [3]: https://gist.githubusercontent.com/anonymous/239a136df2479d36f085e075ddc52287/raw/d6a2fb64ce9e64a8fa1de2962f8bc447e395d14e/ripmime-crash.txt
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYmawJAAoJENuP0xzK19csT1EH/2U0sNoOUjWn12trLUqqZPiX
1P13Pi/qOaJLEtlS1hSE1Nr9beAux5C2h7+kIOZekrLwq36+34HYVmerQT7yz3uz
8NuAWllNWofwfwDde7s9/T28K8YaG3e0+PoMBb0ygWYSsOWMhW3SLJCtWQKSBi/L
qpdaLY+dcmjPvn6z72aBL8N4zcdiHM132lnnT8kdjRO0JL8JXmxkbd22fBot1CQv
pZSHSPHTk6uo9m9e7MI7RPzQAaRhQM1Ju7gO2tDJxRe120afx8Czg7WF4zNoG5+D
NRGgc957r2oRpkdstMlnV4zYdyONssokuo7rcm+ciEzb8AtSuBzrNxhuovV0RUs=
=aqgm
-----END PGP SIGNATURE-----