Bug#977872: ITP: golang-github-cli-safeexec -- safer version of exec.LookPath on Windows
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-cli-safeexec
Version : 1.0.0-1
Upstream Author : Mislav Marohnić , GitHub Inc.
* URL : https://github.com/cli/safeexec
* License : BSD-2-clause
Programming Lang: Go
Description : safer version of exec.LookPath on Windows
safeexec is a Go module that provides a safer alternative to exec.LookPath()
on Windows.
.
The following, relatively common approach to running external commands
has a subtle vulnerability on Windows:
.
import "os/exec"
.
func gitStatus() error {
// On Windows, this will result in .\git.exe or .\git.bat being executed
// if either were found in the current working directory.
cmd := exec.Command("git", "status") return cmd.Run()
}
.
Searching the current directory (surprising behavior) before searching
folders listed in the PATH environment variable (expected behavior)
seems to be intended in Go and unlikely to be changed:
https://github.com/golang/go/issues/38736
.
Since Go does not provide a version of exec.LookPath() that only searches
PATH and does not search the current working directory, this module provides
a LookPath function that works consistently across platforms.
.
Example use:
.
import (
"os/exec" "github.com/cli/safeexec"
)
.
func gitStatus() error {
gitBin, err := safeexec.LookPath("git")
if err != nil {
return err
}
cmd := exec.Command(gitBin, "status")
return cmd.Run()
}
Reason for packaging: Needed by hugo 0.79.1 and up
NHXHide Package Development and Publishing
Hello, I would like to get help from any of the professional members here to develop a package for a tool I developed, NHXHide, and publish it to the Debian repository. As a brief introduction, NHXHide is a custom non-interfering steganography tool that can hide any data inside multimedia files (written in Python). Further details and Usage at Github page: https://www.github.com/NHXTech/NHXHide/readme.md. I would be grateful if one can assist me in this case. Kind Regards.
Bug#977881: ITP: python-django-swapper -- Django Swappable Models
Package: wnpp Severity: wishlist Owner: Michael Fladischer X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-django-swapper Version : 1.1.2 Upstream Author : S. Andrew Sheppard * URL : https://github.com/wq/django-swappable-models/ * License : Expat Programming Lang: Python Description : Django Swappable Models Swapper is an unofficial API for the undocumented but very powerful Django feature: swappable models. Swapper facilitates implementing arbitrary swappable models in your own reusable apps. This is a new dependency for python-django-x509. I intend to maintain it as part of the DPT. -BEGIN PGP SIGNATURE- iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl/hzusRHGZsYWRpQGRl Ymlhbi5vcmcACgkQ/9PIi5l90WqX9gf/V4CQHFmoa+FxzyBAkyWmbBT7Y293TVU3 Nt/zIfEjLnVM0OVnZBGOaJrEIX5UFuA/ueT2GzwkoFduAOow+jenGnWYcUl96tdG i6gJqR5FWYnXfssZcgWfUzF/cf7NT30DhjU4mz+xA/7FiOFyHG9RuefVv2h6OhO4 D1c/Mzo/CUcJqdBgFurMoDlCyUSh3U2svZe/wa0RT9zU19iEBCPN45+HOxyjyrHs MAmvZIyESn/LsH4rerooOv2CzJDxYZsqetqk32dHpgDMV6S3PwelAb6ZIiupSNqM TOEkvZjJMCigw1HL0oOwltezrg1OJZzsmq7JUN4Lj9dxf3aLkBEsuQ== =xPWw -END PGP SIGNATURE-
Bug#977885: ITP: libdata-uriencode-perl -- encodes and decodes complex data structures for use in URI's
Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org Owner: Paul Gevers Severity: wishlist * Package name: libdata-uriencode-perl Version : 0.11 Upstream Author : Paul Seamons perlspam at seamons dot com * URL : https://metacpan.org/release/Data-URIEncode * License : GPL Programming Lang: Perl Description : encodes and decoded complex data structures for use in URI's The world of the web works off of URI's. The Query string portion of URIs already support encoding of key/value paired data - they just don't natively allow for complex data structures. There are modules or encodings that do support arbitrarily complex data structures. JSON, YAML and Data::Dumper all have their own way of encoding complex structures. But then to pass them across the web, you usually still have to URL encode them and pass them via a form parameter. Data::URIEncode allows for encoding and decoding complex (multi level) data structures using native Query String manipulators (such as CGI.pm). It takes complex data and turns it into a flat hashref which can then be turned into a URI query string using URL encoding. It also takes a flat hashref of data passed in and translates it back to a complex structure. I intent to work with the Perl team to get this under their umbrella, but I haven't discussed that yet. My ultimate goal is to package Logitech Squeezebox, however, there's a couple of hurdles first. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Why doesn't nifticlib migrate?
On 2020-12-20 22:10:20 +0100, Paul Gevers wrote: > Hi Steven, > > On 20-12-2020 20:32, Steven Robbins wrote: > > The excuses page says it is good to go, but it hasn't migrated despite > > being 7 > > days past the required 5 days. What's up? > > > > > > Excuse for nifticlib > > Migration status for nifticlib (2.0.0+git186-g84740c2-1 to 3.0.1-4): Will > > attempt migration (Any information below is purely informational) > > Additional info: > > Piuparts tested OK - https://piuparts.debian.org/sid/source/n/nifticlib.html > > 12 days old (needed 5 days) > > Excuses generated Sun Dec 20 18:08:20 2020 > > Our migration software has two phases [1]. The excuses are the result of > the first phase. The package is blocked due to the results of the second > phase. The output of that can be seen at [2], which includes: > trying: nifticlib gifticlib > skipped: nifticlib gifticlib (1, 2, 57) > got: 29+0: a-5:a-23:a-0:a-0:i-0:m-0:m-0:p-0:s-1 > * amd64: libcamitk-dev, libinsighttoolkit4-dev, libotb-dev, libsight-dev > - splitting the component into single items and retrying them > trying: gifticlib > skipped: gifticlib (1, 2, 58) > got: 28+0: a-4:a-23:a-0:a-0:i-0:m-0:m-0:p-0:s-1 > * amd64: gifti-bin, libgiftiio-dev, libgiftiio0 > trying: nifticlib > skipped: nifticlib (1, 3, 57) > got: 30+0: a-6:a-23:a-0:a-0:i-0:m-0:m-0:p-0:s-1 > * amd64: libcamitk-dev, libgiftiio-dev, libinsighttoolkit4-dev, > libotb-dev, libsight-dev > > This means that upgrading nifticlib (alone) would make libcamitk-dev, > libgiftiio-dev, libinsighttoolkit4-dev, libotb-dev, libsight-dev not > installable (at least on amd64). > > Unfortunately, I fail to quickly spot how libcamitk-dev becomes > not-installable (it seems to already be not-installable to me). Migrating nifticlib and gifticlib makes libinsighttoolkit4-dev uninstallable: $ apt install libnifti2-dev libinsighttoolkit4-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libznz3 : Breaks: libnifti2 (<= 3.0) E: Unable to correct problems, you have held broken packages. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
monitoring-plugins_2.3 in experimental
Hi there, Am 19.12.20 um 00:56 schrieb Debian FTP Master:> Changes: > monitoring-plugins (2.3-1~exp1) experimental; urgency=medium > . >* [3031044] New upstream version 2.3 >* [61ef2d7] Droping all patches commited upstream and beeing obsolete with > 2.3 >* [66c44c4] d/control: adding new build-deps fir check_curl >* [59b52dd] d/rules: Adding check_curl to std_plugins >* [5e59ca1] Adding check_curl check commands >* [6cbfc78] check_uptime: Don't ship for now, check_uptime also exist in > nagios-plugins-contrib I uploaded this into experimental. In case there is enough (positive) feedback I'm thinking about to upload this into unstable targeted to bullseye. So please test and give feedback. Thanks and cheers, Jan. -- Never write mail to , you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-@ s+:()>- a+ C$ UL$ P+ L$ !E--- W+++$ N+++ o++ K++ !w---? O M+ !V- PS+ PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y+ --END GEEK CODE BLOCK-- signature.asc Description: OpenPGP digital signature
Bug#977899: ITP: libweasel-driverrole-perl -- API definition for Weasel's driver wrappers
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libweasel-driverrole-perl Version : 0.04 Upstream Author : Erik Huelsmann * URL : https://metacpan.org/release/Weasel-DriverRole * License : Artistic or GPL-1+ Programming Lang: Perl Description : API definition for Weasel's driver wrappers Weasel::DriverRole defines the API for all Weasel drivers to be implemented. By using this role in the driver implementation module, an abstract method is implemented croak()ing if it's called. Weasel is an abstracted web-driver framework. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#977907:
Package: wnpp Severity: wishlist Owner: Gard Spreemann X-Debbugs-Cc: debian-devel@lists.debian.org, g...@nonempty.org * Package name: CLBlast Version : 1.5.1 Upstream Author : Cedric Nugteren and others * URL : https://cnugteren.github.io/clblast/clblast.html * License : Apache-2.0 Programming Lang: C++ Description : Tuned OpenCL BLAS library CLBlast is an OpenCL BLAS library that often can sometimes offer better performance than the clblas that's already in the archive. I will maintain the package, although I might also reach out to the science team.
Do I need a sponsor to submit a new package?
I have written a small utility in Linux to automatically update wallpaper on the desktop from either locally saved images or images retrieved online. It is written in Python, is ridiculously simple code for what it does, and has never failed to run correctly in any version of Linux I have tried it with. I submitted it to the wishlist, and believe that I have followed the rules in that process. If I did things correctly, everything needed is referenced here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976174 Is there a next step that I need to take? Thanks!
im am fed up
why no respond >:
Re: Package dependency versions and consistency
On Fri, Dec 18, 2020 at 04:25:19PM -0800, Josh Triplett wrote: >... > I'm not suggesting there should be 50 versions of a given > library in the archive, but allowing 2-4 versions would greatly simplify > packaging, and would allow such unification efforts to take place > incrementally, via transitions *in the archive* and *in collaboration > with upstream*, rather than *all at once before a new package can be > uploaded*. > > (I also *completely* understand pushing back on having 2-4 versions of > something like OpenSSL; that'd be a huge maintenance and security > burden. That doesn't mean we couldn't have 2-4 semver-major versions of > a library to emit ANSI color codes, and handle reducing that number via > incremental porting in the archive rather than via prohibition in > advance.) It is important to always remember that the main product we are delivering to our users are our stable releases. Right now we are close to the freeze of bullseye. We will security-support bullseye until mid-2024. We do have 4 different versions of autoconf in the archive. This works because autoconf does not have CVEs. If a library is so complex that your "unification efforts in collaboration with upstream" would apply, chances are there will be CVEs if anyone does a security audit of the code. > I think much of our resistance to allowing 2-4 distinct semver-major > versions of a given library comes down to ELF shared libraries making it > painful to have two versions of a library with distinct SONAMEs loaded > at once, and while that can be worked around with symbol versioning, > we've collectively experienced enough pain in such cases that we're > hesitant to encourage it. Our policies have done a fair bit to mitigate > that pain. But much of that pain is specific to ELF shared libraries and > similar. No, the only real pain is providing security support. >... > The > dependency and library mechanisms of some other ecosystems, are designed > to support having multiple distinct versions of libraries in the same > address space, with fully automatic equivalents of symbol versioning. >... How can Debian security support packages from such ecosystems? To meit always feels as if these ecosystems are not interested in providing any support for that. The basic idea behind a distribution like Debian stable or Ubuntu LTS is to provide one set of packages, which will then stay unchanged for 3 or 5 years except for security fixes. There are usecases for rolling release distributions, and there are usecases for stable distributions like Debian. If there is a CVE in a library that is used by 20 different packages in 20 different versions, how does the ecosystem help Debian with applying this CVE fix to all 20 versions with reasonable effort? > - Josh Triplett cu Adrian
Re: im am fed up
On Tue, 2020-12-22 at 21:34 +0100, Richard wrote: > why no respond >: Sir, This is a volunteer organization. Anyone and everyone here contributes soley because they feel like it. You have not paid us anything, therefore, we are not beholden to give you anything. That includes a response to your email. If you want productive responses, I recommend you glance through the code of conduct [1] That being said, we will try to respond to everything, even three word messages that tell us nothing about their problem. However, I could not find any mail from you, at all. Are you sure your email client is set up correctly? [1]: https://www.debian.org/MailingLists/#codeofconduct signature.asc Description: This is a digitally signed message part
Re: im am fed up
I have mailed a few official e-mails and some persons (surname@debian) i have a request On di, 2020-12-22 at 23:28 -0500, Calum McConnell wrote: > On Tue, 2020-12-22 at 21:34 +0100, Richard wrote: > > why no respond >: > > Sir, > This is a volunteer organization. Anyone and everyone here contributes > soley because they feel like it. You have not paid us anything, > therefore, we are not beholden to give you anything. That includes a > response to your email. If you want productive responses, I recommend you > glance through the code of conduct [1] > > That being said, we will try to respond to everything, even three word > messages that tell us nothing about their problem. However, I could not > find any mail from you, at all. Are you sure your email client is set up > correctly? > > [1]: https://www.debian.org/MailingLists/#codeofconduct
Re: im am fed up and we go beyond it
On Wed, Dec 23, 2020 at 06:24:15AM +0100, Richard wrote: > On di, 2020-12-22 at 23:28 -0500, Calum McConnell wrote: > > On Tue, 2020-12-22 at 21:34 +0100, Richard wrote: > > > why no respond >: > > > > Sir, > > This is a volunteer organization. Anyone and everyone here contributes > > soley because they feel like it. You have not paid us anything, > > therefore, we are not beholden to give you anything. That includes a > > response to your email. If you want productive responses, I recommend you > > glance through the code of conduct [1] > > > > That being said, we will try to respond to everything, even three word > > messages that tell us nothing about their problem. However, I could not > > find any mail from you, at all. Are you sure your email client is set up > > correctly? > > > > [1]: https://www.debian.org/MailingLists/#codeofconduct > > > I have mailed a few official e-mails and some persons (surname@debian) > i have a request Vertel gewoon wat je verzoek is. Doe moeite voor wat je wilt. Als wilt plassen, dat mag, ga gewoon naar het toilet. Echter niet zeiken. Inderdaad Richard, het is je gelukt om wat negatieve energie los te krijgen. Weet dat het aan jezelf is om met goede vragen te komen. In http://www.catb.org/~esr/faqs/smart-questions.html de lange versie. Of ik boos ben? Dat is niet belangrijk. Belangrijk is dat wij onze gesamenlijk belangen vinden. Summary: Get beyond whining Regards Geert Stappers DD P.S. An advice: Make a fresh start, assume this email thread never happend -- Silence is hard to parse signature.asc Description: PGP signature
Re: im am fed up and we go beyond it
Duidelijke taal. On Wed, 2020-12-23 at 08:18 +0100, Geert Stappers wrote: > On Wed, Dec 23, 2020 at 06:24:15AM +0100, Richard wrote: > > On di, 2020-12-22 at 23:28 -0500, Calum McConnell wrote: > > > On Tue, 2020-12-22 at 21:34 +0100, Richard wrote: > > > > why no respond >: > > > > > > Sir, > > > This is a volunteer organization. Anyone and everyone here > > > contributes > > > soley because they feel like it. You have not paid us anything, > > > therefore, we are not beholden to give you anything. That > > > includes a > > > response to your email. If you want productive responses, I > > > recommend you > > > glance through the code of conduct [1] > > > > > > That being said, we will try to respond to everything, even three > > > word > > > messages that tell us nothing about their problem. However, I > > > could not > > > find any mail from you, at all. Are you sure your email client > > > is set up > > > correctly? > > > > > > [1]: https://www.debian.org/MailingLists/#codeofconduct > > > > > > I have mailed a few official e-mails and some persons > > (surname@debian) > > i have a request > > Vertel gewoon wat je verzoek is. Doe moeite voor wat je wilt. > > Als wilt plassen, dat mag, ga gewoon naar het toilet. > Echter niet zeiken. > > > Inderdaad Richard, het is je gelukt om wat negatieve energie los te > krijgen. Weet dat het aan jezelf is om met goede vragen te komen. > In http://www.catb.org/~esr/faqs/smart-questions.html de lange > versie. > > > Of ik boos ben? Dat is niet belangrijk. > Belangrijk is dat wij onze gesamenlijk belangen vinden. > > > > Summary: Get beyond whining > > > Regards > Geert Stappers > DD > > > P.S. > > An advice: Make a fresh start, assume this email thread never happend
