Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.
> On May 26, 2020, at 15:10, Mattia Rizzolo wrote: > > * building the package shows this "scary" GCC warning: > |In file included from /usr/include/string.h:495, > | from cryptopass.c:19: > |In function 'strncpy', > |inlined from 'main' at cryptopass.c:200:9: > |/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: > '__builtin___strncpy_chk' specified bound depends on the length of the source > argument [-Wstringop-overflow=] > | 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos > (__dest)); > | | > ^~ > |cryptopass.c: In function 'main': > |cryptopass.c:191:25: note: length computed here > | 191 | passlenbuflen = strlen(argv[3]); > | | ^~~ This prompted me to take a quick look at the source. There are multiple trivially exploitable buffer overflows in this code. E.g. src/cryptopass.c:147-149 [0]: usernamelen = strlen(argv[1]); memcpy(username, argv[1], usernamelen); You could argue this program is only intended to receive input from a trusted user, but is a user meant to comprehend that passing large command line arguments results in memory corruption? Obviously everyone is free to develop code how they like, but IMHO security packages should be using fuzz testing, that would easily find this issue. AFAICT this code base has no test suite. I would suggest adding one as well as fuzzing this code before exposing the downstream public to it. [0]: https://github.com/basilgello/cryptopass/blob/master/src/cryptopass.c#L147-L149
Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.
Control: owner -1 ! Control: tag -1 moreinfo On Sun, May 24, 2020 at 02:22:42PM +, Vasyl Gello wrote: > I am looking for a sponsor for my package "cryptopass" o/ > * Vcs : https://salsa.debian.org/basilgello-guest/cryptopass I'm mostly looking at the VCS, but I'm not ignoring the regular source package either. Things: * you are not using git-buildpackage, instead everything is just thrown into the master branch. Please look into gbp. Since this is a totally new package, I'm actually recommending you just destroy this repository and create it anew, starting with a blank `gbp import-orig`. Please also enable pristine-tar in your local configuration unless you have a reason not to, and I also recommend you put "sign-tags = True" in the DEFAULT section as well. * d/control: + any reason not to go to compat 13? + just to please my OCD, could you please move the Section field up next to Priority? (this is just me, I just can't look at that! :|) + on that note, you should review the Section, since this is not a library from what I can see + the synopsis is not a sentence, as such it shouldn't end with a full stop + also in the synopsis, grammar improvement: s/for generating/to generate/ + in contrast, the long description is made up of whole sentences, but it's not really flowing: "This program can be used to generate passwords from a seed composed by: " is more welcoming to read than your initial line * d/changelog: + Make that only "Initial upload. Closes: #xxx", no need for 3 lines and "initial upload" is kind of standard. * d/copyright: + place the full local URI for the Apache-2.0 License + likewise for the CC0, you only wrote the remote URL + you assert that lib/base64/* is BSD-3-clause, but I can't really say it by looking at the source. Since you are upstream, I urge you to include an extra file (like the referenced README?) explaining the origin of those bundled files * d/rules: + you have clearly copied this file from somewhere without understanding it… didn't you? + that DH_OPTIONS export to make "some magic below work", do you know what? AFAIK it's pretty useless as it is, so please drop that + also go read the section "COMPATIBILITY LEVELS" of debhelper(7), to discover that starting with compat 10 "--with autoreconf" is implied + can you please explain what's so special of this package that you don't want to call ldconfig? Since it's something so odd there ought to be a comment. * d/upstream/metadata: + Contact is obsoleted by Upstream-Contact in d/copyright (avoids duplication) * building the package shows this "scary" GCC warning: |In file included from /usr/include/string.h:495, | from cryptopass.c:19: |In function 'strncpy', |inlined from 'main' at cryptopass.c:200:9: |/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: '__builtin___strncpy_chk' specified bound depends on the length of the source argument [-Wstringop-overflow=] | 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | | ^~ |cryptopass.c: In function 'main': |cryptopass.c:191:25: note: length computed here | 191 | passlenbuflen = strlen(argv[3]); | | ^~~ Overall all of the above are indeed trivial matters, but this is likewise a very trivial project to package. One thing I have to think about is if this is something that debian would benefit to have. I'm not really security-minded, so I tend to be wary about anything that tried to do crypto or handling passwords. I hope some random 3rd party will tell me that this is fine ^^ -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#961628: RFS: shotwell/0.30.10-1 -- digital photo organizer
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "shotwell" Package name: shotwell Version : 0.30.10-1 Upstream Author : Jim Nelson URL : https://wiki.gnome.org/Apps/Shotwell License : LGPL-2.1 Vcs : https://jff.email/cgit/shotwell.git Section : gnome It builds those binary packages: shotwell - digital photo organizer shotwell-common - digital photo organizer - common files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/shotwell Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/shotwell/shotwell_0.30.10-1.dsc or from git: https://jff.email/cgit/shotwell.git/?h=release%2Fdebian%2F0.30.10-1 Changes since the last upload: * New upstream release. - Remove debian/patches/0115-fix_meson_build.patch. * debian/shotwell.manpages: - Install from debin/tmp to make dh_missing happy. * debian/shotwell.install: - Install from debin/tmp to make dh_missing happy. * debian/control: - Switch to debhelper-compat level 13. CU Jörg Frings-Fürst -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#960572: RFS: vim-ale/2.6.0-1 [ITP] (Asynchronous Lint Engine for Vim 8 and NeoVim), vim-vader/0.3.0+git20200213.6fff477-1 [ITP] (simple vimscript test framework)
Control: owner -1 james...@debian.org Le lundi 25 mai 2020 à 14:44:20+0200, Pierre-Elliott Bécue a écrit : > Dear Nicholas, > > Thanks for your work, I'll review it! > > A few preliminary remarks: > > on salsa's repo for vim-ale, you've created a debian/master branch that > is merely the same as upstream/latest for now, and a mymedia/master one > which seems to contain the debian packaging files. > > I'd suggest you either remove mymedia/master in favour of debian/master > (it'd seem more relevant to upload the package from the content of > debian/master), or at least make the mymedia/master branch being the > default branch of the repository on salsa, and discard the debian/master > branch that seems to be useless. > > The same goes for vim-vader. > > My preference would be to rename mymedia/master to debian/master. > > I'll handle both packages, but, next time, please open one RFS per > source package. The fact that both are closely related doesn't really > change a thing to that, and one bug for multiple packages makes it > harder to follow what has already been done and what is to be done. Hi, Since James decided to upload these packages right away, I'll leave that to him. Anyway, you should get your branches sorted out. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
