Re: Bug#858612: ITP: wifiphisher -- Automated phishing attacks against Wi-Fi networks
Hi, Le 25/03/2017 à 11:44, Raphael Hertzog a écrit : > Hi, > > On Sat, 25 Mar 2017, Thibaut Paumard wrote: >> I'm not sure of the benefit for the project of shipping this, > > This is a tool that is shipped in Kali Linux, a Debian derivative and we > are trying to merge back packages useful for penetration testers into > Debian. The benefit is clear for that category of users. Thanks for the pointer. Just out of curiosity, do you intend on using the blends framework for the pkg-security team? >> but do we have ways of protecting our users from it? > > Given that this is mainly "social engineering", the best way to protect > users is to teach them about what can be done securely or not. I'm afraid > that this answer won't satisfy you but the job of the penetration tester > is to point out when some users do not follow best security practices > or when the current practices are just not secure enough. Reading the description of wifiphisher, it looks awfully easy to steal important credentials from anyone who is connected to any wifi, including most "secured" connections, not to mention airport hotspots. If you have pointers about those best security practices, I'll gladly take them. Quickly Googling "pkg-security" and "Debian security" did not reveal a prominent central place for this sort of information. Although not Debian-specific, a starting point at debian.org for raising awareness for our users would be nice. If the pkg-security team could take it on its shoulders... Kind regards, Thibaut.
Re: Bug#858612: ITP: wifiphisher -- Automated phishing attacks against Wi-Fi networks
On Mon, 27 Mar 2017, Thibaut Paumard wrote: > Thanks for the pointer. Just out of curiosity, do you intend on using > the blends framework for the pkg-security team? This is not part of any current plan but I have no objection if someone wants to do the required work. > If you have pointers about those best security practices, I'll gladly > take them. I'm not a penetration tester myself. But a good starting point is to not use "http" at all on connections that you do not trust and also using tools to ensure that you get the same https certificate that you use to get over a secure connection. > Quickly Googling "pkg-security" and "Debian security" did not reveal a > prominent central place for this sort of information. Although not > Debian-specific, a starting point at debian.org for raising awareness > for our users would be nice. If the pkg-security team could take it on > its shoulders... The pkg-security team is about packaging tools, not about this, sorry. https://wiki.debian.org/Teams/pkg-security Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: convention on listen port local or all network interfaces etc. - revision 2
Hi Patrick, On Sun, Mar 26, 2017 at 11:22:00AM +, Patrick Schleizer wrote: > A convention on listen port local or all network interfaces etc. would > be desirable. I agree, though I'm not sure we can get consensus on this… However, I also think that you should restart this discussion once stretch has been released. Now it's not the best time to have such discussions… > Any questions? Any suggestions? What do you think? > > Feedback on the ticket [0] and pull requests on the repository [1] are > welcome. (I haven't looked at neither…) but I'd suggest you file a bug against the "general" pseudo-package in the Debian BTS as that's a more proper place to discuss changes in Debian. Thanks! -- cheers, Holger signature.asc Description: Digital signature
Bug#858830: ITP: node-sha.js -- Streamable SHA hashes in pure javascript
Package: wnpp Severity: wishlist Owner: ro...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-sha.js Version : 2.4.8 Upstream Author : Dominic Tarr (dominictarr.com) * URL : https://github.com/crypto-browserify/sha.js * License : Expat Programming Lang: JavaScript Description : Streamable SHA hashes in pure javascript This module implement SHA hashes in pure javascript. It implement: sha, sha1, sha224, sha256, sha384 and sha512. . Implemention updates incremently internal buffer, so you can hash things larger than allocated memory. This module reuses the typedarrays, thus a constant amount of memory during hash compuation (except when using base64 or utf8 encoding).
Bug#858840: ITP: kytos-utils -- This is a command line interface (cli) for Kytos SDN Platform.
Package: wnpp Severity: wishlist Owner: "Paulo Henrique de Lima Santana (phls)" * Package name: kytos-utils Version : 2017.1b1 Upstream Author : Paulo Henrique de Lima Santana (phls) * URL : https://github.com/kytos/kytos-utils * License : MIT Programming Lang: Python Description : This is a command line interface (cli) for Kytos SDN Platform. This is a command line interface (cli) for Kytos SDN Platform. . With these utilities you can interact with Kytos daemon and manage Network Applications (NApps) on your controller.
Re: changelog practice, unfinalised vs UNRELEASED vs ~version
On Tue, Feb 14, 2017, at 19:42, Ian Jackson wrote:
> Simon McVittie writes ("Re: changelog practice, unfinalised vs UNRELEASED
> vs ~version"):
> > On Mon, 13 Feb 2017 at 09:42:32 +1100, Ben Finney wrote:
> > > I don't see how this complaint is any different from the need to merge,
> > > for example, changes to API documentation and test cases that accompany
> > > a functional change.
> >
> > It's the difference between "sometimes conflicts" and "always conflicts".
>
> This is a very real problem for debian/changelog, but mergechangelogs
> helps a lot. In any case as I say I'm not trying to mandate the
Usable VCSes have pluggable merge drivers, and there are such drivers
for both GNU-style ChangeLog, and debian/changelog[1]. IME, they "just
work". So, yeah, one *can* have the chagelog-update-along-with-change
workflow sanely most of the time nowadays.
I would never use such an workflow unless forced, as I believe the
"proper commit log Tao" is better in the long run, and when your commit
logs are proper (and quite verbose), the natural workflow [2] asks for
changelog-updating commits before release (or maybe at the tip of every
ready-for-integration branch, etc), but...
[1] refer to dpkg-mergechangelogs(1) for the git driver for
debian/changelog, for example.
[2] as in "less busywork" while hacking, and no weird (and possibly
maintenance-hell-creating) disparity from commit log contents to in-tree
changelog contents.
--
Henrique de Moraes Holschuh
Bug#858858: ITP: heaptrack -- heap memory profiler for Linux
Package: wnpp Severity: wishlist Owner: Anton Gladky * Package name: heaptrack Version : 1.0.0 Upstream Author : Milian Wolff * URL : https://github.com/KDE/heaptrack * License : LGPL Programming Lang: C++ Description : heap memory profiler for Linux Heaptrack traces all memory allocations and annotates these events with stack traces. Dedicated analysis tools then allow you to interpret the heap memory profile to: - find hotspots that need to be optimized to reduce the memory footprint of your application - find memory leaks, i.e. locations that allocate memory which is never deallocated - find allocation hotspots, i.e. code locations that trigger a lot of memory allocation calls - find temporary allocations, which are allocations that are directly followed by their deallocation
Bug#858861: ITP: spyder-memory-profiler -- memory profiling plugin for the Spyder IDE
Package: wnpp Severity: wishlist Owner: Ghislain Antony Vaillant * Package name: spyder-memory-profiler Version : 0.1.0 Upstream Author : Spyder Project Contributors * URL : https://github.com/spyder-ide/spyder-memory-profiler * License : Expat Programming Lang: Python Description : memory profiling plugin for the Spyder IDE Long-Description: This is a plugin for the Spyder IDE that integrates the Python memory profiler. It allows you to see the memory usage in every line. . Add a `@profile` decorator to the functions that you wish to profile then press Ctrl+Shift+F10 to run the profiler on the current script, or go to `Run > Profile memory line by line`. . The results will be shown in a dockwidget, grouped by function. Lines with a stronger color have the largest increments in memory usage. This package will be co-maintained by the Debian Science Team, alongside the spyder application.
Re: System libraries and the GPLv2 (was: Re: GnuTLS in Debian)
Florian Weimer schrieb: > Would it be possible to get real legal advice on this matter, with the > concrete goal to find a usable process to leverage the system library > exception in the GPLv2? We should have done that a decade ago... The SFLC can probably help, but an official request to them on behalf of the project should probably be initiated by the DPL. Fortunately there's a DPL election happening, so a perfect time to raise that question to the candidates :-) Cheers, Moritz
Bug#858862: ITP: spyder-line-profiler -- line profiling plugin for the Spyder IDE
Package: wnpp Severity: wishlist Owner: Ghislain Antony Vaillant * Package name: spyder-line-profiler Version : 0.1.1 Upstream Author : Spyder Project Contributors * URL : https://github.com/spyder-ide/spyder-line-profiler * License : Expat Programming Lang: Python Description : line profiling plugin for the Spyder IDE Long-Description: This is a plugin for the Spyder IDE that integrates the Python line profiler. It allows you to see the time spent in every line. Usage . Add a @profile decorator to the functions that you wish to profile then press Shift+F10 (line profiler default) to run the profiler on the current script, or go to Run > Profile line by line. . The results will be shown in a dockwidget, grouped by function. Lines with a stronger color take more time to run. This package will be co-maintained by the Debian Science Team, alongside the spyder application.
Re: Bug#858612: ITP: wifiphisher -- Automated phishing attacks against Wi-Fi networks
On Mon, Mar 27, 2017 at 11:33:07AM +0200, Raphael Hertzog wrote: > I'm not a penetration tester myself. But a good starting point is to > not use "http" at all on connections that you do not trust and also using > tools to ensure that you get the same https certificate that you use to > get over a secure connection. Does the browser shipped with Debian do this by default? Do you need to install an addon? -- Sean Whitton signature.asc Description: PGP signature
