Re: RFS: acsccid (New Upstream Release)
On Fri, Jan 27, 2012 at 11:33 PM, Godfrey Chung wrote: I sent the e-mail to Secure Testing Team at home tonight. Hope that they can receive my e-mail. Thanks! I've added your changes to SVN. If yourself or anyone else wants to get involved in tracking security issues in Debian, please take a look at this page: http://security-tracker.debian.org/tracker/data/report -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6e06hj-ra3s662dlohpnnagtb-e0vkxss3eahtzko8...@mail.gmail.com
Re: RFS: acsccid (New Upstream Release)
Dear Kilian Finally, my package acsccid 1.0.3-1 had been reviewed by Paul and I had modified the package according to his comment. You may be busy at this moment. Please take a look of my package as soon as possible. I would be glad if you uploaded my package for me. Regards Godfrey -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CDE4B10737FB4D8C881849F513F8926F@grasshopper
Re: RFS: acsccid (New Upstream Release)
Dear Paul I sent the e-mail to Secure Testing Team at home tonight. Hope that they can receive my e-mail. Thanks! Regards Godfrey
Re: RFS: acsccid (New Upstream Release)
On Thu, Jan 26, 2012 at 3:24 PM, Godfrey Chung wrote: Why do you duplicate src/92_pcscd_acsccid.rules as debian/libacsccid1.udev? I would suggest deleting debian/libacsccid1.udev and just using the upstream file. Done. I created a symbolic link to upstream file. Why? Isn't the existing file installed by the upstream build system? If not, please send them a patch The src/openct directory is an embedded code copy. You should ask upstream to remove it and build-depend on openct. If they are not willing to do so, then you should do that for Debian. If that isn't possible for whatever reason, please contact the security team and get it added to the embedded code copies file: http://wiki.debian.org/EmbeddedCodeCopies It is not an embedded code copy. acsccid borrowed the internal code from openct to do the smart card protocol (T1). According to the ChangeLog, the source code had been modified. Sounds like the very definition of an embedded code copy. It would be nice if upstream did not do this. Should ccid be removed from Debian? acsccid seems like a fork of it. If it shouldn't be removed, please also get this documented by the security team, they track forks too. No. Can you explain your response here? How can I get this documented by the security team? See the wiki page I pointed at. log_xxd is a internal API provided by pcscd. Therefore, dpkg-shlibdeps cannot find the function from other shared libraries. This means pcscd is not portable to non-ELF platforms (IIRC). lintian complaints: X: libacsccid1: shlib-calls-exit usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Linux/libacsccid.so.1.0.3 The exit function call is generated automatically by flex (tokenparser.l -- tokenparser.c). It seems to be difficult to modify the code. Ok, this is an experimental lintian tag, you can ignore it. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6gbqqs_ecq06g5zdc1gy2bndggodz1ftaiycj7fq7m...@mail.gmail.com
Re: RFS: acsccid (New Upstream Release)
Dear Paul Why do you duplicate src/92_pcscd_acsccid.rules as debian/libacsccid1.udev? I would suggest deleting debian/libacsccid1.udev and just using the upstream file. Done. I created a symbolic link to upstream file. Why? Isn't the existing file installed by the upstream build system? If not, please send them a patch Yes, the upstream does not install the udev file and the udev file is needed to be copied manually. I referred to libccid and found that the package made use of dh_installudev to install udev file. I think this helper script know how to get the udev path. Sounds like the very definition of an embedded code copy. It would be nice if upstream did not do this. I think the upstream will use it if openct exports this useful internal function from the library and the upstream author did not want to reinvent the wheel. Should ccid be removed from Debian? acsccid seems like a fork of it. If it shouldn't be removed, please also get this documented by the security team, they track forks too. No. Can you explain your response here? acsccid is a fork of ccid but it only supports smart card readers from ACS. I don't think we should remove ccid. How can I get this documented by the security team? See the wiki page I pointed at. Which wiki page? I saw this one for http://wiki.debian.org/EmbeddedCodeCopies. Is it another one? Regards Godfrey -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4791545F754C4E05A7F88318D4105220@GODFREYPC
Re: RFS: acsccid (New Upstream Release)
On Thu, Jan 26, 2012 at 6:02 PM, Godfrey Chung wrote: I think the upstream will use it if openct exports this useful internal function from the library and the upstream author did not want to reinvent the wheel. Please contact the openct upstream about that. acsccid is a fork of ccid but it only supports smart card readers from ACS. I don't think we should remove ccid. Sounds like acsccid should be merged into ccid. Which wiki page? I saw this one for http://wiki.debian.org/EmbeddedCodeCopies. Is it another one? Right. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6g39w00no_3yy2jgcjjyg1oiyfe_qik_vsqvm28v_z...@mail.gmail.com
Re: RFS: acsccid (New Upstream Release)
Dear Secure Testing Team I would like to add the following entries to the embedded-code-copies file. acsccid is a fork of ccid and is based on ccid 1.3.11. acsccid - ccid 1.3.11 unfixed (fork) ccid - openct unfixed (modified-embed) - towitoko unfixed (modified-embed) Please correct me if the syntax is wrong. Thanks! Regards Godfrey -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0D1F9B598249487788FA46B6C67ABF92@GODFREYPC
Re: RFS: acsccid (New Upstream Release)
Dear Paul I cannot send the e-mail to the following address. It seems that our SMTP server cannot do the identity verification. Can you help me to forward the e-mail to Secure Testing Team? --- Hi. This is the qmail-send program at hades6.communilink.net. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. secure-testing-t...@lists.alioth.debian.org: 217.196.43.134 does not like recipient. Remote host said: 550-Verification failed for godfrey.ch...@acs.com.hk 550-Called: 203.124.10.222 550-Sent: RCPT TO:godfrey.ch...@acs.com.hk 550-Response: 553 Not our message (#5.7.1) 550 Sender callout failed: Sender adress can't be verified through SMTP check. Giving up on 217.196.43.134. kil...@debian.org: 70.103.162.29 does not like recipient. Remote host said: 550-Verification failed for godfrey.ch...@acs.com.hk 550-Called: 203.124.10.223 550-Sent: RCPT TO:godfrey.ch...@acs.com.hk 550-Response: 553 Not our message (#5.7.1) 550 Sender verify failed Giving up on 70.103.162.29. Regards Godfrey -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2C14928FA32643739B4576BECEA2FD01@GODFREYPC
Re: RFS: acsccid (New Upstream Release)
Dear Paul Thank you for your review. I filed #657110 on lintian to check for commented out Vcs-* fields pointing at collab-maint (which is created by dh_make). Please consider implementing a patch for it so that others don't make the same mistake. Done. I removed the comment. You might want to run wrap-and-sort -s so diffs on debian/control are more readable in future. Done. Why do you duplicate src/92_pcscd_acsccid.rules as debian/libacsccid1.udev? I would suggest deleting debian/libacsccid1.udev and just using the upstream file. Done. I created a symbolic link to upstream file. Upstream is hard-coding the path to libpcsclite.pc in configure.ac, please ask them to stop doing that. AC_PREFIX_DEFAULT should not be needed either. Done. I have forwarded your suggestion to Development Team. debian/watch doesn't need the blank line. I would also suggest using [\d\.]+ instead of .* Done. debian/control misses a build-dep on perl. If perl leaves build-essential then your package will FTBFS. Done. Please use --parallel when calling dh, otherwise you don't respect part of Debian Policy 4.9.1. Done. The upstream README file contains installation info and authors/copyright/license info, which is not useful for Debian users. You might want to get upstream to split those out into README.install, AUTHORS or similar. Done. I have forwarded your suggestion to Development Team. The src/openct directory is an embedded code copy. You should ask upstream to remove it and build-depend on openct. If they are not willing to do so, then you should do that for Debian. If that isn't possible for whatever reason, please contact the security team and get it added to the embedded code copies file: http://wiki.debian.org/EmbeddedCodeCopies It is not an embedded code copy. acsccid borrowed the internal code from openct to do the smart card protocol (T1). According to the ChangeLog, the source code had been modified. Should ccid be removed from Debian? acsccid seems like a fork of it. If it shouldn't be removed, please also get this documented by the security team, they track forks too. No. How can I get this documented by the security team? One warning from dpkg-shlibdeps: dpkg-shlibdeps: warning: debian/libacsccid1/usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Linux/libacsccid.so.1.0.3 contains an unresolvable reference to symbol log_xxd: it's probably a plugin. dpkg-shlibdeps: warning: 1 similar warning has been skipped (use -v to see it). log_xxd is a internal API provided by pcscd. Therefore, dpkg-shlibdeps cannot find the function from other shared libraries. lintian complaints: X: libacsccid1: shlib-calls-exit usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Linux/libacsccid.so.1.0.3 The exit function call is generated automatically by flex (tokenparser.l -- tokenparser.c). It seems to be difficult to modify the code. I have updated the package with the following change log. Please have a look. * New upstream release. * Removed debian/patches/pcsc-lite-1_7_3.patch. * Updated debian/copyright. * Updated debian/libacsccid1.udev with a symbolic link to src/92_pcscd_acsccid.rules. * Removed comment starting with Vcs- and added perl to Build-Depends in debian/control. * Added --parallel option to dh in debian/rules. * Removed a blank line and replaced .* with [\d\.]+ in debian/watch. Regards Godfrey -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/01509DEEED2944F3BABB080BD94FE5D5@GODFREYPC
Re: RFS: acsccid (New Upstream Release)
Here is a review of your package: I filed #657110 on lintian to check for commented out Vcs-* fields pointing at collab-maint (which is created by dh_make). Please consider implementing a patch for it so that others don't make the same mistake. You might want to run wrap-and-sort -s so diffs on debian/control are more readable in future. Why do you duplicate src/92_pcscd_acsccid.rules as debian/libacsccid1.udev? I would suggest deleting debian/libacsccid1.udev and just using the upstream file. Upstream is hard-coding the path to libpcsclite.pc in configure.ac, please ask them to stop doing that. AC_PREFIX_DEFAULT should not be needed either. debian/watch doesn't need the blank line. I would also suggest using [\d\.]+ instead of .* debian/control misses a build-dep on perl. If perl leaves build-essential then your package will FTBFS. Please use --parallel when calling dh, otherwise you don't respect part of Debian Policy 4.9.1. The upstream README file contains installation info and authors/copyright/license info, which is not useful for Debian users. You might want to get upstream to split those out into README.install, AUTHORS or similar. The src/openct directory is an embedded code copy. You should ask upstream to remove it and build-depend on openct. If they are not willing to do so, then you should do that for Debian. If that isn't possible for whatever reason, please contact the security team and get it added to the embedded code copies file: http://wiki.debian.org/EmbeddedCodeCopies Should ccid be removed from Debian? acsccid seems like a fork of it. If it shouldn't be removed, please also get this documented by the security team, they track forks too. One warning from dpkg-shlibdeps: dpkg-shlibdeps: warning: debian/libacsccid1/usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Linux/libacsccid.so.1.0.3 contains an unresolvable reference to symbol log_xxd: it's probably a plugin. dpkg-shlibdeps: warning: 1 similar warning has been skipped (use -v to see it). lintian complaints: X: libacsccid1: shlib-calls-exit usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Linux/libacsccid.so.1.0.3 -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6E0H0bT79t6LLRYzEnRJo=dvvah2udsq2nkvf0yn0q...@mail.gmail.com
