Bug#809623: RFS: telegram-purple/1.2.3-1
- flawfinder yields too many results to be practical (~ 2460 lines). This is
mostly due to libtgl being written in a style that uses static arrays for
everything, including parsing and output.
I've been thinking of making the default for c-a-t-t to limit output
of checks by default, probably to around 10 lines.
Sounds good!
- The output of "POFileSpell" seems to depend on the local dictionaries. It
seems to flag every word in every language I don't speak. (~ 1640 lines)
This is correct, you obviously need to install the relevant
dictionaries for it to be useful.
How about an option that changes the following:
- Current: thousands of warning for French, because the French dict is
missing.
- Suggested: single warning, saying "French dictionary not found
(expected at /usr/share/some/where)"
But I guess this should be reported against POFileSpell, not c-a-t-t, right?
- "suspicious-source" works like a charm. It runs in a fraction of a second,
and outputs only a single line: "./tg-server.tglpub"
That's absolutely correct! I like that program. (I'm not complaining, I'm
admiring the program. The file ./tg-server.tglpub is clearly documented in
the README.md, including a link to a side-project with the sole purpose of
reproducibly generating this single file for public sources.)
Hmm, are you sure?
pabs@chianamo ~/telegram-purple-1.2.3 $ grep tglpub README.md
pabs@chianamo ~/telegram-purple-1.2.3 $
*head-desk*
It looks like I wrote the documentation while tired.
$ grep tlgpub README.md
We no longer ship `tg-server.pub` (old format), but instead
`tg-server.tlgpub` (new format). [snip]
Obviously, the spelling "tlg" is wrong, and should be "tgl". All files
are named correctly. This will be fixed in the next upstream release.
After reading the source code I see that it is some sort of public key.
It is, basing on Telegram's public key. (Has to be requested by mail.
Don't ask me why they had that idiotic idea.)
The tglpub file-format is easy enough to be written with nothing but a
hexeditor; is clearly explained (just three big endian integers); comes
along with a program that demonstrates how to generate the tglpub given
the original pubfile.
In case you wonder why we don't just read the original pubkey:
proprietary file format, and wanted to avoid using a function that
smells like OpenSSL.
- The "Please add some upstream metadata" warning triggers. Since this is
not a scientific project, and there won't be any doi-references, I'm going
to ignore the warning. However, I'm going to use this to ask: Why is that a
warning? Why not include it in the build scripts of the deb-science
packaging team instead?
The upstream metadata stuff has nothing to do with science apart from
being initiated by the science team. Just include the parts that apply
to this package. I don't understand why so many people have this
misconception.
Because it's the first and only thing at which I looked when opening the
page for the first few times. Now I finally actually read it (oh god,
sorry dear author of the page). I included it into 1.2.4-2. (See
separate mail.)
- The problem of bashisms relates to the program checkbashism, like
incompatibilities between make-implementations to checkgmakeism, a program
I'd like to see being written. I made up the name. I have no idea how to do
that. So far, we did it by trial and error, and change something whenever a
user complains. AFAIK, by now we only support gmake, due to the use of
"ifdef", which should be ".ifdef" in bsd-make:
https://github.com/majn/telegram-purple/issues/137#issuecomment-167970054
That would be a good check to have but for now I don't know of any
implementation or anyone interested in working on such a thing.
Sure, no pressure, just wanted to mention it, in case a
Make-compatibility-guru reads along :P
Sorry for the wall of text, but you *did* ask for it :P
One goal of c-a-t-t is to expose more people to the tools, eventually
leading to better tools :)
I wasn't even remotely aware of the sheer flood of such tools, each of
them doing different things, and then there's sanity check so basic that
you didn't even need a "tool" for that and just used grep/find/etc.
Thank you for the program, the work, the feedback :D
Regards,
Ben Wiederhake
Reply to: