Bug#834398: ITP: r-bioc-rbgl -- R interface to the graph algorithms contained in the BOOST library

[Christopher Hoskin]

Package: wnpp
Severity: wishlist
Owner: Christopher Hoskin 

* Package name: r-bioc-rbgl
  Version : 1.48.1
  Upstream Author : Vince Carey , Li Long 
, R. Gentleman 
* URL : 
http://www.bioconductor.org/packages/release/bioc/html/RBGL.html
* License : Artistic-2.0
  Programming Lang: R
  Description : R interface to the graph algorithms contained in the BOOST 
library

 RBGL is part of the BioConductor GNU R suite. It is a fairly extensive and
 comprehensive interface to the graph algorithms contained in the BOOST C++
 libraries.

 Many BioConductor packages are maintained by the Debian Med team, and I
 would be very happy for this package to be maintained in that way.

 I am not a Debian Developer, so will require a sponsor.

 Thankyou.

Bug#834400: ITP: mkchromecast -- cast Linux Audio to your Google Cast Devices

[Muammar El Khatib]

Package: wnpp
Severity: wishlist
Owner: Muammar El Khatib 

* Package name: mkchromecast
  Version : 0.3.2
  Upstream Author : Muammar El Khatib 
* URL : http://mkchromecast.com/
* License : MIT
  Programming Lang: Python
  Description : cast Linux Audio to your Google Cast Devices

 This is a program to cast your macOS audio, or Linux audio to your Google Cast
 devices. It is written in Python, and it streams via node.js, ffmpeg, or
 avconv.

 mkchromecast is capable of using lossy and lossless audio formats provided
 that ffmpeg or avconv are installed. Additionally, a system tray menu is also
 available.

--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Re: UID and GID generation

[Ian Jackson]

Adam Borowski writes ("Re: UID and GID generation"):
> Actually, I do like this idea; obviously with reasoning contrary to the
> original report.  In any small organization or a family, where you have an
> ad hoc set of machines without centralized user management, it is nice to
> have consistent uids.


Maybe you want sync-accounts, from chiark-utils.  Centralized user
management on the cheap.

Ian.

Bug#834417: ITP: libjs-microplugin.js -- Lightweight plugin / dependency system for libraries

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: libjs-microplugin.js
  Version : 0.0.3
  Upstream Author : Brian Reavis 
* URL : https://github.com/brianreavis/microplugin.js
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : Lightweight plugin / dependency system for libraries

 MicroPlugin is a lightweight drop-in plugin architecture for your
 JavaScript library. Plugins can declare dependencies to other plugins
 and can be initialized with options (in a variety of formats). It is
 AMD-compatible and it works identically in Node.js and in a browser.

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#834426: ITP: meqtrees-cattery -- MeqTrees-based frameworks for simulation and calibration of radio interferometers

[Gijs Molenaar]

Package: meqtrees-cattery
Owner: Gijs Molenaar 
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org,debian-as...@lists.debian.org,
debian-pyt...@lists.debian.org

* Package name: meqtrees-cattery
  Version : 1.4.0
  Upstream Author : Oleg Smirnov
* URL : https://github.com/ska-sa/meqtrees-cattery
* License : GPL2
  Programming Lang: Python
  Description : MeqTrees-based frameworks for simulation and
calibration of
radio interferometers
MeqTrees is a software package for implementing Measurement Equations. This
makes it uniquely suited for simulation and calibration of
radioastronomical data, especially that involving new radiotelescopes and
observational regimes.

It will maintained within the Debian Astronomy Working Group. A git
repository
will be created on alioth [1].

Best regards

Gijs

[1]
https://anonscm.debian.org/cgit/debian-astro/packages/meqtrees-cattery.git

-- 
Gijs Molenaar
http://pythonic.nl

Bug#834425: ITP: meqtrees-timba -- core MeqTrees package for implementing and solving arbitrary Measurement Equations

[Gijs Molenaar]

Package: meqtrees-timba
Owner: Gijs Molenaar 
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org,debian-as...@lists.debian.org,
debian-pyt...@lists.debian.org

* Package name: meqtrees-timba
  Version : 1.5.0
  Upstream Author : Oleg Smirnov
* URL : https://github.com/ska-sa/meqtrees-timba
* License : GPL2
  Programming Lang: C++
  Description : core MeqTrees package for implementing and solving
arbitrary
Measurement Equations
MeqTrees is a software package for implementing Measurement Equations. This
makes it uniquely suited for simulation and calibration of
radioastronomical data, especially that involving new radiotelescopes and
observational regimes.

It will maintained within the Debian Astronomy Working Group. A git
repository
will be created on alioth [1].

Best regards

Gijs

[1] https://anonscm.debian.org/cgit/debian-astro/packages/meqtrees-timba.git

Re: Please, provide a fixed Cloud Image URL for Debian

[Martinx - ジェームズ]

On 11 August 2016 at 01:45, Paul Wise  wrote:

> On Thu, Aug 11, 2016 at 5:58 AM, Martinx - ジェームズ wrote:
>
> >  When we talk about Cloud Images for OpenStack, both Ubuntu and CentOS
> > provides fixed URLs that never changes.
>
> BTW, there is a debian-cloud mailing list for Cloud discussions.


Oh, I wasn't aware of it... I'll re-post this message there instead...
Sorry about the buzz!:-)

Re: copyright precision

[Stefano Zacchiroli]

On Fri, Aug 12, 2016 at 02:19:43AM +0200, gregor herrmann wrote:
> AFAIK there are plans around sources.d.n to use the d/copyright files
> in Copyright-Format 1.0.  Currently they are browsable at
> https://sources.debian.net/copyright/ but IIRC some more analysis is
> planned.

We do have downstreams for machine-readable debian/copyright files.

I'm in touch with companies who have used those to cross-check their
independent findings about copyright/licenses of source code that goes
into their end-user products. I haven't yet had time to watch Kate
Stewart's DebConf16 talk video [1], but her and other people at the
Linux Foundation are working in reusing our machine-readable copyright
information too.

[1]: https://debconf16.debconf.org/talks/100/

For the actual technical roadmap of sources.debian.net/copyright,
Orestis (Cc:-ed) might be more up to date than me --- or ask on
debian-qa@, where Debsources development is discussed.

The fact we do (or don't) have downstreams for copyright information of
course does not counter Simon's considerations in this thread about
being clear about why we do maintain that information.

For me personally it has always been a very natural self-imposed duty:
as package maintainers we have to check copyright/license of all files
to ensure we do not distribute non-DFSG stuff; compiling a list of
extracted information to better keep an eye on how it evolves over time
seems a good practice; and if you're going to have a list it's much
better to make it readable by a computer.

The problem we're having here is clearly about *tooling*. If we had a
good toolchain to compile and audit machine-readable debian/copyright
files without sweating, nobody would complain. We have improved a lot
over time here (cme and lintian checks comes to mind), but there's still
a long way to go. FOSSology integration in Debian seems the natural next
step here. I believe Kate talked about that too in her DebConf16 talk.

Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: copyright precision

[Simon McVittie]

On Mon, 15 Aug 2016 at 18:17:52 +0200, Stefano Zacchiroli wrote:
> The problem we're having here is clearly about *tooling*. If we had a
> good toolchain to compile and audit machine-readable debian/copyright
> files without sweating, nobody would complain.

I have three slightly devil's-advocate responses to that:

* If we had a good toolchain to compile and audit this stuff, people
  and companies who want to know the copyright holders could just use
  that to inspect the upstream source code and cut out the middle-man.

* Our copyright files are only correct inasmuch as upstream's copyright
  attribution is correct. I would guess that a large majority of patch
  submitters, even implementors of somewhat major features that are
  certainly copyrightable, don't actually add a copyright notice to the
  files they touched. I certainly don't do that 100% consistently for my
  own contributions; I'm careful to preserve *other people's* copyright
  notices and license grants if I incorporate someone else's code into a
  project, but I think I can confidently say that not all upstreams
  are even that conscientious.

* I will continue to complain as long as my "source" packages are
  expected to contain 87kB monsters like
  ,
  which is fairly clearly not anyone's preferred form for modification,
  and if we're being honest probably not really anyone's preferred form for
  consumption either. (That file is actually generated, by the slightly
  less offensive 11kB
  
,
  because I really didn't want to insert the CC licenses by hand; but
  Policy and ftp-master practice require the generated file to be part
  of the source upload. See also .)

Regards,
S

Bug#834435: ITP: statsprocessor -- word generator based on per-position Markov chains

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: statsprocessor
  Version : 0.11
  Upstream Author : Jens Steube 
* URL : https://github.com/hashcat/statsprocessor
* License : MIT
  Programming Lang: C
  Description : word generator based on per-position Markov chains

Statsprocessor is a word generator based on per-position Markov chains
packed into a single stand-alone binary. It generates candidate words based
on a Hashcat format .hcstat file by using this information to determine which
letter is following which letter based on the analysis of the original input
dictionary used to generate the .hcstat. The resulting words can then, for
example, be postprocessed and fed into Hashcat or other password recovery
tools.

Bug#834438: ITP: princeprocessor -- standalone password candidate generator using the PRINCE algorithm

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: princeprocessor
  Version : 0.21
  Upstream Author : Jens Steube 
* URL : https://github.com/hashcat/princeprocessor
* License : MIT
  Programming Lang: C
  Description : standalone password candidate generator using the PRINCE 
algorithm

Princeprocessor is a password candidate generator and can be thought of
as an advanced combinator attack. Rather than taking as input two different
wordlists and then outputting all the possible two word combinations though,
princeprocessor only has one input wordlist and builds "chains" of combined
words. These chains can have 1 to N words from the input wordlist
concatenated together.
The name PRINCE is used as an acronym and stands for PRobability INfinite
Chained Elements, which are the building blocks of the algorithm.

Re: copyright precision

[Nikolaus Rath]

On Aug 15 2016, Simon McVittie  wrote:
> On Mon, 15 Aug 2016 at 18:17:52 +0200, Stefano Zacchiroli wrote:
>> The problem we're having here is clearly about *tooling*. If we had a
>> good toolchain to compile and audit machine-readable debian/copyright
>> files without sweating, nobody would complain.
>
> I have three slightly devil's-advocate responses to that:
>
> * If we had a good toolchain to compile and audit this stuff, people
>   and companies who want to know the copyright holders could just use
>   that to inspect the upstream source code and cut out the middle-man.

I think even the best tooling wouldn't be able to automatically generate
correct copyright files. However, it would make it feasible to keep an
initially-correct copyright file correct over time (by flagging
potentially copyright affecting changes in an upstream release and
providing a straightfoward way to integrate those changes).

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Status of kbd console-data and console-setup

[Cesare Leonardi]

On 12/08/2016 19:50, Samuel Thibault wrote:

Felipe Sateler, on Fri 12 Aug 2016 17:44:20 +, wrote:

localed by itself does little more than updating /etc/default/keyboard et
al[1] (it can set XKBMODEL, XKBVARIANT, XKBLAYOUT and XKBOPTIONS in that
file). It then tries to invoke systemd-vconsole, which is the service
that actually tries to setup the console, but it is not enabled in debian.


I mean setting up console's and X11's keyboard.


Does systemd now sets up X11 keyboard too?!


Yes. But in debian it is patched to only touch /etc/default/keyboard.


Ok, then it could simply get the list of available maps from xkb-data,
since that's the source for console-setup too.


Systemd-localed already uses xkb-data for the X11 keymaps and, as far i 
know, systemd's /etc/vconsole.conf is substantially the equivalent of 
Debian's /etc/default/keyboard.
Furthermore upstream's systemd-vconsole-setup service can also set 
keymaps and fonts on early boot providing some handy kernel command line 
arguments, like "vconsole.keymap".


The problem is that currently localectl can get/set x11-keymaps but 
cannot get/set text-console keymaps because it cannot find. And always 
returns errors.


I wrote here, before filing bugs, to know if there were some plans about 
console keymaps, because solving it potentially concern more packages: 
systemd, keyb, console-setup and perhaps others.

I think that in the next days i'll try to revive this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790955

Regarding the vlock part of my initial message, in the meantime i've 
filed these bugs:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833843
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833888

Cesare.

Re: copyright precision

[Stefano Zacchiroli]

On Mon, Aug 15, 2016 at 10:53:53AM -0700, Nikolaus Rath wrote:
> > * If we had a good toolchain to compile and audit this stuff, people
> >   and companies who want to know the copyright holders could just use
> >   that to inspect the upstream source code and cut out the middle-man.
> 
> I think even the best tooling wouldn't be able to automatically generate
> correct copyright files. However, it would make it feasible to keep an
> initially-correct copyright file correct over time (by flagging
> potentially copyright affecting changes in an upstream release and
> providing a straightfoward way to integrate those changes).

Indeed. I don't think the ideal tooling here could be fully automated
(at least in the most general case), it could/should be semi-automated
at best. In that respect, it doesn't seem in any way different from
other machine-readable information that we extract from upstream
projects. Take dependencies: in many cases they could be extracted from
other kinds of metadata (or, failing that, from README files, developer
documentation, etc). But then they can be wrong, and need curation by a
human maintainer for correctness; or at least usefulness.

Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: UID and GID generation

[Jeremy Stanley]

On 2016-08-15 01:09:20 +0200 (+0200), Martin Bammer wrote:
[...]
> I thought that the IDs for system services are fixed. Static ID
> mapping is a nice idea which would be helpful for system services.
[...]

Some of them are fixed: https://wiki.debian.org/SystemGroups

There are compiled-in defaults for SYS_GID_MIN and SYS_UID_MIN of
100 so GIDs and UIDs you see lower than that are fixed assignments.
Red Hat/Fedora have been continuing to add to the list on their
distros over the years, and have to explicitly bump these minimums
in /etc/login.defs as they eventually grew past 100:
https://git.fedorahosted.org/cgit/setup.git/tree/uidgid
-- 
Jeremy Stanley

Re: copyright precision

[Stefano Zacchiroli]

On Mon, Aug 15, 2016 at 05:59:43PM +0100, Simon McVittie wrote:
> * If we had a good toolchain to compile and audit this stuff, people
>   and companies who want to know the copyright holders could just use
>   that to inspect the upstream source code and cut out the middle-man.

I've comment on this in my follow-up to Nikolaus.

> * Our copyright files are only correct inasmuch as upstream's copyright
>   attribution is correct.

Right. But that doesn't make it less valuable. In provenance theory
knowing that someone has witnessed that someone else has said something
is a useful data point. And [FOSS] software provenance is a big deal
these days. If the price to pay for doing so is not too high, there is
an important role for Debian to be played there.

> * I will continue to complain as long as my "source" packages are
>   expected to contain 87kB monsters like
>   
> ,
>   which is fairly clearly not anyone's preferred form for modification,
>   and if we're being honest probably not really anyone's preferred form for
>   consumption either.

I beg to disagree (at least) with the latter. No matter the size, once
parsed you can query that file with questions like "what's the
license/copyright of this file according to [this] Debian [package]?".
That's one of the thing that the Debsources API is meant to allow.


But to be clear: I'm not advocating for keeping nor ditching anything in
particular here. I've been asked which level of integration of
machine-readable debian/copyright exists in Debsources. I've answered to
that, testifying that we do have downstreams of our *current*
debian/copyright files. No matter that, Debian can decide: that is not
worth maintaining that information / that is worth only if better
tooling is available / that is worth only if someone else shows up to do
the job / etc. Like it or not, downstreams will cope.

Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: copyright precision

[Scott Kitterman]

On Monday, August 15, 2016 05:59:43 PM Simon McVittie wrote:
> On Mon, 15 Aug 2016 at 18:17:52 +0200, Stefano Zacchiroli wrote:
> > The problem we're having here is clearly about *tooling*. If we had a
> > good toolchain to compile and audit machine-readable debian/copyright
> > files without sweating, nobody would complain.
> 
> I have three slightly devil's-advocate responses to that:
> 
> * If we had a good toolchain to compile and audit this stuff, people
>   and companies who want to know the copyright holders could just use
>   that to inspect the upstream source code and cut out the middle-man.
> 
> * Our copyright files are only correct inasmuch as upstream's copyright
>   attribution is correct. I would guess that a large majority of patch
>   submitters, even implementors of somewhat major features that are
>   certainly copyrightable, don't actually add a copyright notice to the
>   files they touched. I certainly don't do that 100% consistently for my
>   own contributions; I'm careful to preserve *other people's* copyright
>   notices and license grants if I incorporate someone else's code into a
>   project, but I think I can confidently say that not all upstreams
>   are even that conscientious.
> 
> * I will continue to complain as long as my "source" packages are
>   expected to contain 87kB monsters like
>  
>  >, which is fairly clearly not anyone's preferred form for modification, and
> if we're being honest probably not really anyone's preferred form for
> consumption either. (That file is actually generated, by the slightly less
> offensive 11kB
>  
>  pl/>, because I really didn't want to insert the CC licenses by hand; but
> Policy and ftp-master practice require the generated file to be part of the
> source upload. See also .)

Personally, I think the bulk of the reason we should care about 
debian/copyright is to achieve license compliance.  For license compliance we 
need to reproduce the upstream copyright notice and license, so even if it was 
easy to download source and inspect with better tool, it does nothing to help 
what we need to do to keep the binary parts of the archive legal to 
distribute.

I think your points are orthogonal to the reasons we do debian/copyright.

Yes, copyright files are hard and unfun and we could use better tools, but I 
don't think anyone is writing or reviewing debian/copyright because they enjoy 
it.  

Scott K
Wearing no hats

Re: copyright precision

[Markus Koschany]

On 15.08.2016 21:50, Scott Kitterman wrote:
> On Monday, August 15, 2016 05:59:43 PM Simon McVittie wrote:
>> On Mon, 15 Aug 2016 at 18:17:52 +0200, Stefano Zacchiroli wrote:
>>> The problem we're having here is clearly about *tooling*. If we had a
>>> good toolchain to compile and audit machine-readable debian/copyright
>>> files without sweating, nobody would complain.
>>
>> I have three slightly devil's-advocate responses to that:
>>
>> * If we had a good toolchain to compile and audit this stuff, people
>>   and companies who want to know the copyright holders could just use
>>   that to inspect the upstream source code and cut out the middle-man.
>>
>> * Our copyright files are only correct inasmuch as upstream's copyright
>>   attribution is correct. I would guess that a large majority of patch
>>   submitters, even implementors of somewhat major features that are
>>   certainly copyrightable, don't actually add a copyright notice to the
>>   files they touched. I certainly don't do that 100% consistently for my
>>   own contributions; I'm careful to preserve *other people's* copyright
>>   notices and license grants if I incorporate someone else's code into a
>>   project, but I think I can confidently say that not all upstreams
>>   are even that conscientious.
>>
>> * I will continue to complain as long as my "source" packages are
>>   expected to contain 87kB monsters like
>>  
>> >> , which is fairly clearly not anyone's preferred form for modification, and
>> if we're being honest probably not really anyone's preferred form for
>> consumption either. (That file is actually generated, by the slightly less
>> offensive 11kB
>>  
>> > pl/>, because I really didn't want to insert the CC licenses by hand; but
>> Policy and ftp-master practice require the generated file to be part of the
>> source upload. See also .)
> 
> Personally, I think the bulk of the reason we should care about 
> debian/copyright is to achieve license compliance.  For license compliance we 
> need to reproduce the upstream copyright notice and license, so even if it 
> was 
> easy to download source and inspect with better tool, it does nothing to help 
> what we need to do to keep the binary parts of the archive legal to 
> distribute.

We would also achieve license compliance if we did it the way Fedora/Red
Hat have been doing it for years now. Not a single DFSG-approved license
requires us to reproduce its full license text in a new file called
debian/copyright, not even the BSD-licensed ones.

> I think your points are orthogonal to the reasons we do debian/copyright.
> 
> Yes, copyright files are hard and unfun and we could use better tools, but I 
> don't think anyone is writing or reviewing debian/copyright because they 
> enjoy 
> it.  

I would like to take this opportunity to thank Simon McVittie for
contributing to this thread. I completely agree with everything he has
written so far especially with the points presented at [1]

So yes, copyright files are hard and unfun but why should we continue to
write them the way we do if we are not legally bound to do so? Sure I
agree that a machine-readable copyright file that lists every
contributor and license would be preferable but in reality those files
get outdated very quickly and only a few maintainers really care about
updating this file after importing a new upstream release.

I still don't understand why we punish ourselves by reproducing every
license text verbatim if we could easily add every DFSG-approved license
to /usr/share/common-licenses and simply refer to it. Some people argue
that a Creative Commons license is not a common license but apparently
they have never packaged a game or multimedia application before. Get
rid of the distinction between common-licenses and DFSG-approved licenses.

Every DFSG-free license should be available on a Debian system. Full
stop. Don't require that people have to quote the same license text over
and over again in their packages. That would be a step forward.

Regards,

Markus

[1] https://lists.debian.org/debian-devel/2016/08/msg00181.html





signature.asc
Description: OpenPGP digital signature

Re: copyright precision

[Jonas Smedegaard]

Quoting Markus Koschany (2016-08-15 23:02:06)
> So yes, copyright files are hard and unfun but why should we continue 
> to write them the way we do if we are not legally bound to do so?

Same reason that we should continue to care about ability to install 
multiple major versions of a library concurrently, and that daemons are 
not only linked correctly but also sensibly configured and started by 
default.

Not because we are legally bound to do so, but because we want to do our 
job as distributors properly.  We appreciate good quality packaging!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: UID and GID generation

[Michael Lustfield]

> [...]

In the original scenario, the concern was was with shared media having
uid/gid numbers that don't match what's on the system. In that
scenario, this was viewed as a security concern. This is not a
security concern because once someone has physical access to your
unencrypted data, it's no longer your data. That's just an unfortunate
truth. You can give me a HD w/ Windows on it, tell me you set up the
file system permissions to be really super duper secure, but... I'm
just going to walk around the file system as if you gave me higher
than administrator access. Whatever isn't encrypted is now something I
have access to.

For the above scenario, the let's say the data is encrypted. If you're
giving the other party the key so they can open it... it's no longer
your data.

The next scenario I recall from this thread was about the small
business scenario. The typical response to that is obviously
centralized authentication. I know scenarios where that's not possible
or the logistics are absurd. The next best thing is configuration
management utilities. In my personal opinion, if your company is large
enough to have servers, it's large enough that config management is no
longer optional.

If you can go along with that, you can get something like this (salt example):
local_users:
  - michael:
uid: 4001
gid: 4001
pwd: 
keys:
  - ssh_key1
  - ssh_key2
  - timmy:
uid: 4002
gid: 4002
pwd: 
  - freddy:
terminated: True

When tools like sssd take a remote uid/gid and translate that to a
local translated uid/gid, I don't believe that's a security concern so
much as a concern of things breaking if you start getting collisions.
Ya, that's a security concern if sssd generates uid/gid numbers that
collide with numbers that other tools that want to use those
specifically, but I'm convinced this behavior has nothing to do with
security. This behavior only makes collisions unlikely, it does not,
in any way, guarantee that collisions will never happen.

In fact... Story time! One of the first times I started playing with
sssd, I was rolling it out in a mid-size enterprise (~24,000
employees). One a few servers, the uid/gid numbers that sssd came up
with collided with over 80% of the existing local system users. This
was a design issue that needed to be resolved, not something that
needed a band-aid. Because centralized user management already
existed, miscellaneous uid/gid numbers were sent up river to AD and
then every system was migrated to using those numbers. End result...
collisions can't happen because we don't let them.


tl;dr -- Randomizing uid/gid numbers does not improve security, it
just decreases the probability of that security hole being accessible.
Enforcing the same uid/gid everywhere *will* prevent collisions.


Sorry, I got a bit long winded. That's what I get when I write fun
emails on my break. :(

Bug#834466: ITP: libjs-sifter.js -- Library for textually searching arrays and hashes of objects

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: libjs-sifter.js
  Version : 0.4.1
  Upstream Author : Brian Reavis 
* URL : https://github.com/brianreavis/sifter.js
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : Library for textually searching arrays and hashes of objects

 Sifter is a client and server-side library (via UMD) for textually
 searching arrays and hashes of objects by property – or multiple
 properties. It's designed specifically for autocomplete. The process
 is three-step: score, filter, sort.
 .
  * Supports díåcritîçs.
 .
For example, if searching for "montana" and an item in the set has
a value of "montaña", it will still be matched. Sorting will also
play nicely with diacritics.
 .
  * Smart scoring.
 .
 Items are scored / sorted intelligently depending on where a match
 is found in the string (how close to the beginning) and what
 percentage of the string matches.
 .
  * Multi-field sorting.
 .
 When scores aren't enough to go by – like when getting results for
 an empty query – it can sort by one or more fields. For example,
 sort by a person's first name and last name without actually
 merging the properties to a single string.
 .
  * Nested properties.
 .
 Allows to search and sort on nested properties so you can perform
 search on complex objects without flattening them simply by using
 dot-notation to reference fields (ie. nested.property).

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: Introducing default-mysql-* metapackages

[Rene Engelhard]

Hi,

On Sun, Jul 10, 2016 at 05:22:22PM +0300, Otto Kekäläinen wrote:
> Hello maintainers of packages that depend in MySQL/MariaDB!

Not everyone is required to read -devel. Mailing them where they read
it (and be it Cc'ing them) would be better.

I am subscribed to -devel but still missed this mail (though I knew there
was something ongoing)

> BEFORE: Build-Depends: libmysqlclient-dev
> AFTER: Build-Depends: default-libmysqlclient-dev
> 
> BEFORE: Depends: mysql-server | virtual-mysql-server OR Depends:
> mariadb-server | virtual-mysql-server
> AFTER: Depends: default-mysql-server | virtual-mysql-server
> 
> BEFORE: Depends: mysql-client | virtual-mysql-client OR Depends:
> mariadb-client | virtual-mariadb-client
> AFTER: Depends: default-mysql-client | default-mysql-client
 
ITYM virtual-mysql-client :)

> If a maintainer knows that his/her package only works with one
> variant, then the package can depend directly on that package and not
> use the default-mysql-* (matches one) or virtual-mysql-* (matches any)
> schemes. Please get in touch if this applies to you. At the moment
> there should be no such packages, but in the future cases like this
> can arise when MySQL and MariaDB develop diverging feature sets.

Well, I know of packages needing MySQL 5.7 and/or failing to build against
MariaDB for other reasons. e.g. mysql-connector-c++. Upstream is Oracle,
so they obviously won't care about MariaDB..

> Packages built against default-mysqlclient-dev and link using
> "-lmysqlclient" will end up with a shared library dependency on either
> libmysqlclient.so.X or libmariadbclient.so.X depending on the default
> defined by the release team at build time. These will be provided by
> the libmysqlclient18 (soon to be libmysqlclient20) and
> libmariadbclient18 packages, which will be co-installable. Packages
> which require particular functionality available from only one of the
> forks may Build-Depend directly on libmysqlclient-dev or
> libmariadbclient-dev and then link using "-lmysqlclient" or
> "-lmariadbclient" respectively. Again, please get in touch if this
> applies to you.

See above.

So this one could still use libmysqlclient-dev?

Or we keep a working version with MariaDB, but then again there's other
packages like mysql-workbench also wanting 1.1.7 (and thus MySQL 5.7)...

> The default-mysql-* metapackages will be uploaded to Experimental soon
> and to Unstable once we are confident there are no regressions. Once
> they are available in Unstable, we will announce this on

I have seen those accepted in unstable this morning so.. :)

Regards,

Rene

Re: UID and GID generation

[Andrey Rahmatullin]

On Mon, Aug 15, 2016 at 01:09:20AM +0200, Martin Bammer wrote:
> Does Windows save usernames for access rights?
No, NTFS permissions are tied to SIDs which are like UNIX UIDs/GIDs but
unique for non-default entities, because they include the computer SID
(those may be non-unique if a system was cloned though, but NTFS
permissions are not better than UNIX permissions for removable storage.).

https://en.wikipedia.org/wiki/Security_Identifier

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: copyright precision

[Andrey Rahmatullin]

On Tue, Aug 16, 2016 at 01:10:42AM +0200, Jonas Smedegaard wrote:
> > So yes, copyright files are hard and unfun but why should we continue 
> > to write them the way we do if we are not legally bound to do so?
> 
> Same reason that we should continue to care about ability to install 
> multiple major versions of a library concurrently, and that daemons are 
> not only linked correctly but also sensibly configured and started by 
> default.
> 
> Not because we are legally bound to do so, but because we want to do our 
> job as distributors properly.  We appreciate good quality packaging!
It's at least worth a discussion whether nitpicking at d/copyright is
really helping the package quality at all, and if it's worth it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature