libudfread & shairplay accepted: thank you for mentoring!
Dear colleagues, Finally the packages I prepared (libudfread & shairplay) were accepted into unstable. I would like to say "thank you" to Mattia Rizzolo, teammates at Multimedia Team and the FTP Team for all the efforts to make it possible. Without you, that'd be a hard task! -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 signature.asc Description: PGP signature
Bug#961919: RFS: shairplay/1.0-1 [ITP] -- AirPort Express server emulator.
Hi Mattia! Fixed version and copyright issues (removed ~exp thingy) and re-targeted to unstable. Lintian on my side does not list any errors, however mentors one reports the bug closed does not belong to the package. Of course I can file another bug but maybe there is more elegant solution? -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library
Hi Mattia! Good to know you are back! Hope you are well :) >Mhh, would you please instead consider joining it now, rather than move >stuff around later? I don't think I saw your joining mail in the last >20 days (sorry for ghosting - I had some personal matters going on). >Then, I notice that you are bumping the version while uploading to >mentors. In the end we shall only upload a -1 with only one changelog >entry to the archive, so feel free to just remove and re-upload the -1 >version to mentors (IIRC you can also just re-upload the same version >and it would overwrite it). I fixed the versioning and maintainership of the package and re-uploaded it cleanly as 1.0.0-1 targeting unstable (since I know now that experimental is basically unstable + some NEW queue with breaking changes) I will reopen this bug now & send an 'official' team join request. Now, after I overhauled Kodi package (including copyrights) and made it and all deps building and running on buster-bpo, I think I am eligible to join :) -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library
Hi Paul! So static libs present in packages like popt are remnants of the past and the general practice now is to discourage shipping all kinds of static libraries unless it is Go/OCaml… as mentioned in this wiki page? I looked at it before, but I try understanding what is considered best practices now. -- Vasyl Gello June 1, 2020 1:57:09 PM UTC, Paul Wise написав(-ла): >On Mon, Jun 1, 2020 at 1:42 PM Vasyl Gello wrote: > >> I often link software statically, especially targeting Android. >> So I guess keeping static library won't hurt as part of -dev >> package. > >Where dynamic libraries are available there are usually only downsides >to static libraries, in Debian we try to not distribute static >libraries unless there is a good reason. > >https://wiki.debian.org/StaticLinking > >-- >bye, >pabs > >https://wiki.debian.org/PaulWise signature.asc Description: PGP signature
Bug#961919: RFS: shairplay/1.0-1 [ITP] -- AirPort Express server emulator.
Hi Mattia! >* d/control: > + vcs is set to your private space, but the package is team maintained Fixed to myself as maintainer, same as other package. > + why did you decide to use "shairplay-bin" instead of just > "shairplay"? I thought source and binary packages of the same name would confuse ftp archive. So I followed the "kodi-bin" path first. Seems I was wrong in my doubts as mentors queue chewed the fixed release just fine! > + drop the full stops from the synopsis (lintian flags this, didn't you > see it?) Done. >* d/changelog: > + it's not closing an ITP Done. >* d/libshairplay-dev.install: > + same as the other pacakge regarding the .a file. Keeping the .a files as explained in the other package ;) >* d/shairplay-bin.install: > + imho, you could just reduce the line length with "usr/bin" and > "usr/share/man" without specifying the single files, since there is > no risk here to pick up stuff from other binary packages accidentally Yes, makes sense. Fixed. (doing same with libs screwed up installer, so as a rule of thumb I'll try being verbose where needed) >* d/rules: > + beware of what that dh_installdocs call you did actually do. I > believe you don't want that. hint: check the package contents. Removed that as now we have manpage. > + you are -X'ing the .la file in dh_install? is that really needed? > + same as the other package regarding dh_missing. Fixed by putting .la into d/not-installed. >* d/patches: > + did you forward them? if you did please add some headers following > DEP-3. The upstream is not maintained + basically the patches fix Debian build. I set them to "not-needed". >* d/watch: > + since now uscan supports scanning bare git repositories, I think you > should add a watchfile novertheless Best catch for today! :) Especially after I crafted the config which can repack stuff from the git HEAD :) >Incidentally, the git repository and what you uploaded to mentors are >slightly different: > >|--- shairplay-0.9.0+git20180824/debian/control 2020-05-31 02:00:00.0 >+0200 >|+++ shairplay-0.9.0+git20180824/debian/control 2020-05-31 02:00:00.0 >+0200 >|@@ -34,7 +34,7 @@ >| . >| Currently only AirPort Express emulation is supported. >| . >|- This package installs the shairplay server executable >|+ This package installs the shairplay server executable. >| >| Package: libshairplay-dev >| Architecture: any > I re-created the repo again to match the uscan-retrieved and repacked tars and pushed the new iteration of pacjage to mentors queue. > > >NOTE: I haven't reviewd the copyright yet. > I revised it and removed parts we don't use (AirTV-Qt). There was both licensing mess and Qt incompatibilities so I just added that folder to Files-Excluded section in d/copyright and re-uscan-ed the source :) I also added files not covered by narrower scopes (*, like .gitignore, makefile.am, configure.ac) as LGPL-2.1+ same as Debian patch. Hope it is corect approach given the LICENSE file of upstream does never mention these files. -- Vasyl Gello
Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library
>* d/control: > + Vcs-* have to point to the packaging repository, not the upstream > one. Since this is something maintained by the multimedia team > (according to Maintainer) it should have a repo within the multimedia > team space. Fixed by setting Maintainer to me until I get into the team. I have not even raised the application intent yet. > + Homepage points to the upstream VCS: doesn't this project have a real > homepage? Well, it is, but it is sometimes not accessible. Added it anyway. > + Both descriptions are way way too short (1 line). please strive to > find at least 3 lines... >* d/*.dirs > + those two files are totally useless, get rid of them Shot them dead ;) >* libudfread-dev.install > + you are installing the .a file: do you really need it? As a personal > policy I try to remove static libraries rather than adding them… I often link software statically, especially targeting Android. So I guess keeping static library won't hurt as part of -dev package. >* d/changelog: > + Please add the "Initial upload" words in there :) Doen :) >* d/rules: > + since you are using dh compat 13, you can go and use > "execute_before_dh_installexamples" instead of the current override > + you may prefer to add that .la file in d/not-installed instead of > overriding dh_missing that way (also relevant if you stop installing > the .a file). >* d/copyright: Good catch, thanks! Now I can keep not-installable things sane. > + I see that debian/* has a different license than the rest of the > package. Theoretically that might cause issue if for example sombody > writes a patch for debian, place it under the debian/* license (GPL2+ > in this case). That patch then it would taint the upstream license, > as combining code with LGPL2.1 and GPL2+ leads to something that is > only GPL2+, likely something that upstream wouldn't want. > + furthermore, the project is not released under LGPL-2.1, but > LGPL-2.1+ ... please pay attention to these details Yes, I double-checked their licenses and fixed d/copyright > + in the copyright you wrote "2014-2020 VLC authors and VideoLAN", but > I can't find any year later than 2017. Lastly, I see all files have > only one "Author:" listead in them, I'd find nice if you added at > least a Comment: line in that "Files: *" paragraph mentioning that > single author. Done > + you missed m4/attributes.m4 - please take note that that GPL-2+ file > has a special exception Done >* you uploaded a .asc file, but you have not provided either public > signing key in d/upstream/signing-key.asc nor set an appropriate pgp > option in d/watch. Nor I can find any signature on the upstream > repository (note that I haven't tried to check the signature). Where > is it coming from? It was my signature as recommended in one of thousand Debian Wiki pages I read. As you clarified in pr8vate, this was useless so I recreated repo and pushed the fixed package to mentors queue. Thanks for review! :) -- Vasyl Gello
Bug#961429: Subject: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.
Dear Mattia and Matthew! First of all I would like to thank you for all the efforts you did to teach me how to do proper Debian packaging. Your reviews made me rethink some practices I followed and it already helps me in my activities outside of Debian. Yesterday I found out the original Cryptopass Chrome extension is no longer maintained and its repository archived. While I fixed the issues spotted in previous reviews and pushed the new upstream version 1.1.0 and corresponding Debian repo on Salsa, I would like to withdraw the package from the queue. Earlier I mentioned the passwordmaker-cli package I found long after I wrote cryptopass. Its Android app is actively maintained, in contrast to the CLI sources, so I will likely propose the fixes incorporating cryptopass scheme into Password Maker (https://www.passwordmaker.org). Once there is new upstream release, I will coordinate with Cord Beermann (the pm-cli maintainer) to have it packaged. I do still appreciate additional reviews on packaging and security of cryptopass, because I thought it could be a great example of "making a small pavkage to learn Debian packaging". Maybe I will even write a series of blog posts about Debian packaging and my experience with it. Sincerely, -- Vasyl Gello signature.asc Description: PGP signature
Bug#961919: RFS: shairplay/1.0-1 [ITP] -- AirPort Express server emulator.
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "shairplay" * Package name: shairplay Version : 0.9.0+git20180824-1 Upstream Author : juh...@iki.fi * URL : https://github.com/juhovh/shairplay * License : LGPL-2.1+ * Vcs : https://salsa.debian.org/basilgello-guest/shairplay Section : libs It builds those binary packages: libshairplay0 - AirPort Express server emulator (shared library). shairplay-bin - AirPort Express Server emulator (executable file). libshairplay-dev - AirPort Express Server emulator (development files). To access further information about this package, please visit the following URL: https://mentors.debian.net/package/shairplay Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/shairplay/shairplay_0.9.0+git20180824-1.dsc Changes since the last upload: * Initial upload Please note that it us basically a #961477 with changed source package name to match upstream. Regards, -- Vasyl Gello
Bug#961477: Updating source package name throws Lintian errors
I have revised the previous iteration of Debian patch for libshairplay, specifically fixed the source package name to match upstream repository name. Now Lintian throws an error "Package closes bugs in wrong way" despite of retitle. I am closing this bug and opening a new RFS with source package name "shairplay". -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#961417: reopen
reopen 961417 = thanks -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.
Hi Matthew!
Thanks for the continued review! You read my mind now?)
>
>Now that I read the remainder of the main source file, I spotted a completely
>separate issue, src/cryptopass.c:375-384 [1]:
>
>/* Clean up everything */
>
>for (counter = 0; counter < 10; counter++) {
> memset(derivedpassword, 0, PASSWORD_BUFFER_SIZE);
> memset(domain, 0, MAX_INPUT_SIZE);
> memset(masterpassword, 0, MAX_INPUT_SIZE);
> memset(passlenbuf, 0, PASSWORD_LENGTH_BUFFER_SIZE);
> memset(salt, 0, SALT_BUFFER_SIZE);
> memset(username, 0, MAX_INPUT_SIZE);
>}
>
>This does not do what you think it does. Either these duplicated memsets are
>redundant or the compiler will optimize them all away observing the targets
>are unused after this. The way to erase something in a way the compiler cannot
>elide is a single memset_s(). However, the program is about to exit and be
>torn down by the operating system, so even this would be redundant.
>
>Your intent (I am guessing) is to prevent an attacker reading these values out
>of program memory. However, an attacker with this ability can simply ptrace
>cryptopass or attach to it with a debugger. I think some thought should be put
>into the threat model for this program and it should probably have a more
>thorough security review before it is packaged.
The threat model is obviously not against an attacker with live root or
hypervisor access. Rather not to leave unwanted things for possible cold-boot
attacks.
Thanks for mentioning memset_s. I see it is C11-specific so if I target older
standard on source level, I will have to do cleanup manually.
--
Vasyl Gello
Re: Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.
Hi Wookey! >OK, but you have to build new packages in a sid chroot too to check >they work, as that's the suite they get uploaded to. It's fine to >package in such a way that the package also builds in buster, but the >primary target of a new package in debian is always sid (unstable). So I can target debhelper-compat 12 to keep it buildable on buster or I shoukd strictly go with 13 as Mattia suggested? -- Vasyl Gello
Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.
Hi Mattia! >I just used the current default in Debian sid, which is GCC 9. > >You should be building your packages in a chroot (possibly using wrapper >tools such as pbuilder or sbuild) to, as from what you said you aren't >building them in sid. I am building in chroot but targeting buster as primary target of this chroot is Kodi :) Will check against GCC 10 in a separate nsjail, thanks :) -- Vasyl Gello
Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.
Hi Matthew! >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 Ouch! That was kinda chilling! :) Finding bugs for others does not guarantee yourself from doing your own ones. > I would suggest adding one as well as fuzzing this code before exposing the > downstream public to it. Will fix the issues and add testsuite && fuzzcorp ASAP. BTW I fixed all the stuff GCC 8.3.0 reported me with FORTIFY_SOURCE=2 before pushing code to GitHub. Did you use GCC 10? Cheers, -- Vasyl Gello
Bug#961477: libshairplay
CC: bal...@balintreczey.hu, sramac...@debian.org This is also for Kodi 19.0 "Matrix" targeting experimental. -- Vasyl Gello
Bug#961477: RFS: libshairplay/1.0-1 [ITP] -- AirPort Express server emulator
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "libshairplay" * Package name: libshairplay Version : 0.9.0-1 Upstream Author : juh...@iki.fi * URL : https://github.com/juhovh/shairplay * License : LGPL-2.1+ * Vcs : https://salsa.debian.org/basilgello-guest/libshairplay Section : libs It builds those binary packages: libshairplay0 - AirPort Express server emulator (shared library). shairplay - AirPort Express Server emulator (executable file). libshairplay-dev - AirPort Express Server emulator (development files). To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libshairplay Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libs/libshairplay/libshairplay_0.9.0-1.dsc Changes since the last upload: * Initial release Regards, -- Vasyl Gello
Bug#961429: Subject: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "cryptopass" * Package name: cryptopass Version : 1.0.0-1 Upstream Author : Vasyl Gello * URL : https://github.com/basilgello/cryptopass * License : Apache-2.0 * Vcs : https://salsa.debian.org/basilgello-guest/cryptopass Section : libs It builds those binary packages: cryptopass - CLI utility for generating long, unguessable passwords. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/cryptopass Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/cryptopass/cryptopass_1.0.0-1.dsc Changes since the last upload: * Initial release * Upload to unstable * Closes: 960187 Regards, -- Vasyl Gello signature.asc Description: PGP signature
Bug#961417: libudfread
Hi Sebastan! Not libudf (part of libcdio) but libudfread (which this RFS is about): https://github.com/xbmc/xbmc/pull/17612 On Sun, 24 May 2020 15:37:47 +0200 Sebastian Ramacher wrote: > Hi Vasyl > > On 2020-05-24 12:20:30 +0000, Vasyl Gello wrote: > > This is part of my preparation of Kodi 19.0 "Matrix" packaging: > > https://salsa.debian.org/basilgello-guest > > Where does kodi now need libudf? > > Cheers > -- > Sebastian Ramacher -- Vasyl Gello signature.asc Description: PGP signature
Bug#961417: libudfread
This is part of my preparation of Kodi 19.0 "Matrix" packaging: https://salsa.debian.org/basilgello-guest -- Vasyl Gello signature.asc Description: PGP signature
Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libudfread" * Package name: libudfread Version : 1.0.0-1 Upstream Author : VideoLAN Project * URL : https://code.videolan.org/videolan/libudfread * License : LGPL-2.1 * Vcs : https://code.videolan.org/videolan/libudfread Section : libs It builds those binary packages: libudfread0 - UDF reader library libudfread-dev - Development headers for UDF reader library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libudfread Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libu/libudfread/libudfread_1.0.0-1.dsc Changes since the last upload: * Closes: 781399 Regards, -- Vasyl Gello signature.asc Description: PGP signature
