in
time for inclusion in buster.
On behalf of the release team,
Niels Thykier
signature.asc
Description: OpenPGP digital signature
Niels Thykier:
> Hi,
>
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
> * It is a substantial hardening feature
> * Upstream has vastly reduced the performance penalty for x86
> * The ma
ased on the current information?
>
> cu
> Adrian
>
It reflects all the issues we are aware of at the present time (except
for archive-{coverage,uptodate}, which can be seen from
https://buildd.debian.org/stats/).
If you believe we have overlooked an issue or an update, please do not
hesitate to let us know. :)
Thanks,
~Niels
Niels Thykier:
> [...]
>
> As for "porter qualification"
> =
>
> We got burned during the Jessie release, where a person answered the
> roll call for sparc and we kept sparc as a release architecture for
> Jessie. However, we
John Paul Adrian Glaubitz:
> On 09/30/2016 06:08 PM, Niels Thykier wrote:
>> I strongly /suspect/ that "no porters" for powerpc will imply the
>> removal of powerpc for Stretch. It may or may not be moved to ports
>> (assuming someone is willing to sup
or may not be moved to ports
(assuming someone is willing to support it there).
Not sure I can answer your 2nd question though.
~Niels
ended further testing/research
* s390x: 2 OK
Over all, most people (who answered it) was positive towards the switch.
Based on this, I suspect that if we make PIE default in Stretch, then
we will do it for all architectures. That said, you will be notified if
that default changes for Stret
t it requires
less work from individual maintainers (and presumably has no notable
downsides in the final result).
Thanks,
~Niels
[1] Example spec files for this case seems to be something like:
pie-compile.specs
"""
*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}
ails to -ports and -devel make any sense.
>
Ah, sorry I had indeed forgotten to set Reply-To. :)
> Maybe debian-release with CC debian- or to you personally and
> you'll collect the info?
>
Please send the replies to debian-release. :)
Thanks,
~Niels
not> ready to have -fPIE/-pie enabled by default.
"""
Niels, on behalf of the release team
[0] Enabling -fPIE/-fpie by default would harden debian systems against certain
attacks. See https://lintian.debian.org/tags/hardening-no-pie.html for
mo
Philipp Kern:
> On 2016-06-05 12:01, Niels Thykier wrote:
>> * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
>>s390x
>>- *No* blockers at this time from RT, DSA nor security.
>>- s390, ppc64el and all arm ports have DSA concerns.
&
rt of the arch release
> qualification anyway IMHO.
>
> Regards,
>
Hmm, the rebootstrap idea is interesting as a new requirement. I will
look into it.
Thanks,
~Niels
signature.asc
Description: OpenPGP digital signature
John Paul Adrian Glaubitz:
> Hi Niels!
>
> On 06/05/2016 12:01 PM, Niels Thykier wrote:
>> Beyond mips64el, we are not aware of any new architectures for Stretch.
>>
>> I kindly ask you to:
>>
>> * Porters, please assert if your architecture is targeting St
).
- DSA/Security/RT: Please use the word "blocker" or "RC" for issues
that *must* be solved for you to be willing to support the
architecture.
Thanks,
~Niels
signature.asc
Description: OpenPGP digital signature
On 2013-11-03 16:03, Steven Chamberlain wrote:
On 03/11/13 10:54, Niels Thykier wrote:
Come to think of it; maybe we should have a BTS page for each of the
ports (e.g. a pseudo package in the BTS).
We've had this on kfreebsd, due it to having been a release goal:
http://udd.debian.org
On 2013-11-03 23:04, Steve Langasek wrote:
On Sun, Nov 03, 2013 at 11:54:34AM +0100, Niels Thykier wrote:
[...]
I suppose a sponsor-only DD could be sufficient, provided that the
sponsor knows the porters well enough to be willing to sign off on e.g.
access to porter boxes. I guess
On 2013-10-29 17:48, Ian Jackson wrote:
Niels Thykier writes (Re: Bits from the Release Team (Jessie freeze info)):
[...]
As mentioned we are debating whether the 5 DDs requirement still makes
sense. Would you say that we should abolish the requirement for DD
porters completely? I.e. Even
On 2013-11-03 15:49, Thorsten Glaser wrote:
Niels Thykier dixit:
[...]
Until we have a clear definition of actively maintained ports, I would
recommend porters to err on the side of being verbose over being silent.
I’ve held off on the m68k side because I think the role call was only
On 2013-11-03 16:54, Niels Thykier wrote:
On 2013-11-03 15:49, Thorsten Glaser wrote:
Niels Thykier dixit:
[...]
Until we have a clear definition of actively maintained ports, I would
recommend porters to err on the side of being verbose over being silent.
I’ve held off
On 2013-10-29 16:05, Ian Jackson wrote:
Niels Thykier writes (Bits from the Release Team (Jessie freeze info)):
Results of porter roll-call
===
...
Summary table:
Arch || DDs || NMs/DMs || Other || Total
On 2013-10-19 16:38, Jeremiah C. Foster wrote:
Hello,
On Sun, Oct 13, 2013 at 05:01:31PM +0200, Niels Thykier wrote:
[snip freeze policy]
Hi,
I s/-arm/-ports/'ed the CC, since I figured the rest of the porters
would find the answer equally interesting.
Results of porter roll-call
) with your concerns or
corrections.
At this time, I have *not* updated the arch qualification table yet. I
will do that in a couple of days. We will also follow up on this in the
next bits from the release team.
~Niels
[AP] http://release.debian.org/jessie/arch_policy.html
[CD] I may (or may
On 2013-09-01 09:33, Niels Thykier wrote:
Hi,
As we announced in [LAST-BITS], we would like to get a better idea of
that status of the ports, to make an informed decision about which
port can be released with jessie. One of the steps is to get an
overview of which of the porters are (still
a DD|I am a DM|I am not a DD/DM
YOUR NAME
Niels, on behalf of the release team
[LAST-BITS] http://lists.debian.org/debian-devel-announce/2013/08/msg6.html
[WIKI] https://wiki.debian.org/ArchiveQualification/Jessie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux
is the future.
And then there's non-kernel work as well, making sure that all your
favourite tools and applications work well on the Hurd might be a good
way to get started.
Regards,
/Niels
alextj [EMAIL PROTECTED] writes:
how can I unset a translator for example to umount a cdrom?
I think it's settrans -g. (For go away)
/Niels
. it should reveal more about the Hurd way of doing
things.
Regards,
/Niels
have no writable disks, the system must be
reasonably stable without swap, or one has to fake some swap by by
somwhow putting a swap file inside the ramdisk (ugly and wastes some
more memory).
Regards,
/Niels
as root filesystem could also work,
either with passive unionfs and tmpfs translator settings on well
chosen nodes on disk, or with a startup script that installs active
translators.
Does it work to install active and/or passive translators, in
particular unionfs, on / ?
/Niels
the problems they saw in smbfs.
Regards,
/Niels
some only by using PAM-tools. And I don't particularly like md5
passwords either; the idea is good, but the current standard and
implementation is far too ugly and obscure for my taste).
Regards,
/Niels
, and that doesn't seem like a
reasonable threshold at all.
/Niels
port, in order of
importance:
1. It's faster
2. It's maintained
3. It's smaller
Something like that. Perhaps you should also add that L4 is more
modern and seems more interesting than Mach.
/Niels
diminished, and the flexibility and modern design of the Hurd will
come to be properly appreciated.
I wouldn't anticipate that... On L4, it will still be multithreaded
servers sending messages to eachother, and probably about as hard to
debug. The L4 port addresses other things.
/Niels
think of Palladium as a way to get the worst out
of the DMCA, just as patented features in M$ file formats (w*ndows
media, perhaps the next version of the w*rd format) are designed to
get the worst out of the patent system. The combination of technology
and law is scary.
/Niels
and distribution of playback software which circumvents
http://wiki.ael.be/index.php/EUCD-Status
Thanks for the clarification.
/Niels
creating new password entries,
which probably requires some level of support in the passwd program.
/Niels
provoked corruption
in the past).
* Sync the filesystem and remove the ext2 translator.
* Start over.
/Niels
and ISO-8859-1.def from
http://www.lysator.liu.se/~nisse/archive.
I'm somewhat annoyed that this isn't fixed properly in the texinfo
dist.
/Niels
.
/Niels
://www.lysator.liu.se/ for
details. Mail me if you need any help setting it up.
/Niels
openssh, which
ones are relevant depend on context.
Regards,
/Niels
=lshcontent-type=text/vnd.viewcvs-markup
Regards,
/Niels
license or permission to use it for educational
purposes or any other purposes.
Regards,
/Niels
that).
/Niels
/urandom.
/Niels
not present, that tells the application that it has
to use it's own workarounds and entropy collection code, something
which any portable crypto library or application will have to support
anyway.
/Niels
from Roland, or some other person familiar with both glibc and POSIX.
Regards,
/Niels
Olivier Péningault [EMAIL PROTECTED] writes:
le mer 23-10-2002 à 23:33, Niels Möller a écrit :
But that's all I've seen. So is anybody actually working on a hurdish
networking stack? I've seen no signs of that.
If nobody works on it, I am volunteer. And if someone does it, I am
ready
be replaced sooner
or later. And someone (Jeff Bailey, IIRC) said a while ago that he'd
like to hack on that, but I read that as wish, not much more.
But that's all I've seen. So is anybody actually working on a hurdish
networking stack? I've seen no signs of that.
/Niels
machine up.
Hmm, iirc it locked up my terminal, but not the entire machine. I ran
it on dryden, and I think I was able to login again and kill the
process.
/Niels
.
Regards,
/Niels
with the operating system, be that /dev/urandom or prngd or
whatever.
/Niels
the farm means that some essential server, like
exec or proc, have died and that there's basically no hope to recover
except by rebooting the machine.
Regards,
/Niels
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
a new $x$ prefix for it).
/Niels
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
or less. One alternative is to have the *translator* talk
directly to the hardware, so that you don't have to hack the kernel
(you'd still need to run the translator as root, though). Moving
device drivers in general out from the kernel and into userspace
programs is a long term plan.
Regards,
/Niels
the idea to look how svgalib is realized, maybe this
would be a good starting point?
Might be. You'd also need a decent spec for the graphics hardware.
Regards,
/Niels
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
, it would make sense to make
/etc/password not readable by the not-logged-in user. You still need
to be able to query the passwd server though, otherwise login wouldn't
work.
/Niels
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
.
Regards,
/Niels
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
of few, the systems will look quite similar to
a user, but quite different to a hacker. And debian's audience
includes both users and hackers, right?
/Niels
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
little use for firewalling, except to help isolate broken or
unmaintained machines from the outside world. And in this case, the FW
is usually a separate box.
Regards,
/Niels
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
provide a fake device port for the subhurd to use, not giving it
direct access to the real Mach device port, would be a start, I guess.
But I'm mostly ignorant about Mach device access.
Regards,
/Niels
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
is just one example, and / another) would
definitely be useful too, but that seems like a more delicate kind of
interaction.
As for terminology, I think it makes sense to talk about some kind of
parent-child relationship when one hurd controls the device accesses
of another.
Regards,
/Niels
netwinder boot sequence.
Regards,
/Niels
,
/Niels
recursively
Perhaps the right way is to add another cp option for copying passive
translator settings, and have -a imply that option?
I think cp -a is pretty useful, at least on systems where cp is aware
of all filesystem features.
/Niels
directories, and copying
translator-settings for non-directories, would do what you want.
/Niels
(like its documentation), then I
still have to do it on a system that glibc supports. If I try to
unpack it on, say, Solaris, configure refuses to create any makefiles.
I hate GNU software. =\
Then why are you reading or posting to debian-hurd?
/Niels
, to the
satisfaction of both C and C++ programmers?
(And before putting too much energy into fixing or debating cthreads,
please note that we all hope that cthreads will be obsolete soon).
Regards,
/Niels
. For a mouse device you might want to set/clear dtr. For a
keyboard you might want to set/clear raw mode. Etc.
To me, this sounds like just another case where property lists are the
right thing.
/Niels
the sources is not good enough.
You may want to look at the Yarrow code in Nettle-1.5 which I released
a few hours ago. You can read the chapter on randomness at URL:
http://www.lysator.liu.se/~nisse/nettle/nettle.html#Randomness.
Regards,
/Niels
.
And at last, you'd want to convert all the almost-arexx hacks that
exist in various programs, e.g. mozilla -remote and emacs-client, to
take advantage of the new facilities.
Happy hacking!
/Niels
for PF_LOCAL. */
#define PF_INET 2 /* IP protocol family. */
#define PF_AX25 3 /* Amateur Radio AX.25. */
#define PF_IPX 4 /* Novell Internet Protocol. */
...
/Niels
almost doing
that already, with nodes that support both file and directory
operations.
This said, I'm not sure we need meta files/resource forks. I believe
properties lists would be nice, put I'm not sure it's very useful to
open a property the same way you open a file.
/Niels
information like ~1.17~ at the end of the filename
seems a little ugly. Perhaps each versioned file could also be a
directory? cat foo.c gives the latest version of foo.c. ls foo.c
lists available versions, cat foo.c/17 gives version 17.
Best regards,
/Niels
that contains an mpeg
movie of some friend playing with his or her cats, well, why can't I
do that? ;-)
Regards,
/Niels
? Does it fit in 31
bits?
/Niels
list and also a
little on bug-hurd. Particular features that are crucial for the hurd
and seem non-trivial to implement on L4 are port rights and no-senders
notifications.
/Niels
shadowfs a try...
Regards,
/Niels
on the command line is probably
not the right way to tell it to do that.
Regards,
/Niels
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
[EMAIL PROTECTED] (Niels Möller) writes:
3. Is there a reasonable way to give a user additional uid:s
automatically at login?
No, but perhaps there should be.
One way to do it might be analogous to supplimentary groups: Have a
file
) port means when
pfinet doesn't run as root. This seems a little harier than I'd
like).
Regards,
/Niels
is a feasible alternative in the not
too distant future. L4 is significantly harder; not much code is
written, and there are some fundamental questions that haven't been
answered yet.
And L4-hurd might still use OSKit device drivers (although I don't
really know how well it fits together).
/Niels
and Grub have some
similarities, and I think it would be a good thing to merge them). I
don't know about other architectures, but I suspect they also don't
use lilo.
Regards,
/Niels
heard of
anybody using that, so it's probably more or less broken.
Unfortunately, I lack the knowledge to implement this myself, but well
here's my idea.. if someone wants to take it, i wish a lot of luck.
They'll need it ;-)
/Niels
).
I don't know anything about C, but maybe I could help, too?
I was about to suggest that you run strace to see what the procss is
doing before it hangs. But then I remembered. How useful is current
rpctrace?
/Niels
, delete the files in
question, and run automake -a. Or something like that.
/Niels
.
And to make it a little more robust, one could have it not ignore
postrm and prerm scripts, but rather fail in that case. (And then you
could have --no-scripts --force if you really want to).
/Niels
.
If you don't want backup files, simply disable them in emacs or
whatever program created them in the first place.
Regards,
/Niels
better with translators, as
have been discussed on this list recently).
Happy hacking,
/Niels
.
Sorry about that. I use the from address [EMAIL PROTECTED] (Niels
Möller). I find it a little odd that a MUA parses an rfc 822
_comment_ for mail addresses in that way.
Regards,
/Niels
there certainly are some
exceptions).
/Niels
.
Would porting oskit to alpha be a good way to get hurd on non-x86
machines? According to the oskit home page, it seems that it currently
works only on x86 and strongarm.
Regards,
/Niels
with pfinet). But using absolute
filenames should not be the normal way of doing things.
Am I making any sense to you?
Regards,
/Niels
PS. When thinking some more, I realize that I don't know if a
translator is installed on an inode or on a filename. But in any
case, as startup
guess GNU sh-utils is the right place.
/Niels
Jeff Sheinberg [EMAIL PROTECTED] writes:
Niels Möller writes:
exec kill $@
isn't good enough? If it has to be written in C for whatever reason, I
guess GNU sh-utils is the right place.
How about using this construct to access the arguments, as it is
more
on Hurd and Linux
(on each hardware platform). Then as long as a program doesn't depend
on services outside of glibc (like direct linux syscalls, mach
syscalls, open(/proc/something/or/other), etc, the same binaries
will work on both systems.
But we're not there yet, as far as I know.
/Niels
moving the Hurd away from its current µ-kernel, Mach.
Best regards,
/Niels
Oystein Viggen [EMAIL PROTECTED] writes:
Combined with some kind of capabilities support, this could prove quite
a versatile (and did I mention cool ;) security feature for the hurd,
though.
Capabilites seem easy enough. This is how...
Let's look at the ftpd example. You create a
Marcus Brinkmann [EMAIL PROTECTED] writes:
The strangeness kicks in when the files are created in /tmp. No matter
who I rmauthed from, the files will appear owned by user and group root
with the default umask. This means that I can 'cat /tmp/somefile',
and actually get what I want in
1 - 100 of 150 matches
Mail list logo
