Charles Baker wrote:
> The axyftp GUI allows the user to save the "jumbled" password. The
> "jumbled" password
> is saved in a ~/.axyftp directory. The file containing the jumbled
> password has permissions
> set to 600. This project includes only an inbound OSR at this time.
What is the al
> >>4). New nbt manpage
> >>
> >> The following SMF properties will be now part of nbtd manifest
> >> and will be set via sharectl command by authorized users.
> > How does this project meet the SMF policy:
> > http://opensolaris.org/os/community/arc/policies/SMF-policy/
> >
> > I'm still confused on how changing the size of structures
> > is mitigated in a patch release. What am I misunderstanding?
> >
>
> The IPFILTER_VERSION (see ipnat(7i)) is used to keep track of user
So part of this case, so far unstated is that IPFILTER_VERSION
is
On Tue, Apr 22, 2008 at 04:23:48PM -0700, John Plocher wrote:
> Seriously. If we don't ever intend to put any engineering effort
> into these things to make them work [at all, better, as expected]
> on OpenSolaris, we shouldn't be mixing them into the core OS source
> tree (aka the ON consolidati
Hi, all
This case is due timeout tomorrow. If all are satisfied with the answers
to from Simon, I'll close the project as approved tomorrow.
1. Authentication: responsibility of PSARC/2008/021
2. Single dialog? This has been carefully considered and it was finally
decided to use two dialogs.
3. A
ers.
thanks
Charles
-- next part --
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080422/89226377/attachment.html>
Joerg Barfurth wrote:
> Hi,
>
> Darren J Moffat schrieb:
> [...]
>> Implementation Notes
>>
>> The module only supports the auth stack.
>>
>
> This isn't consistent with the 'upstream documentation' section:
My mistake.
>> --- Upstream Documentation ---
>>
> [...]
>> ...
>
ed to bring it up to date with current
> technology and support it as part of Solaris?
>
> Gary..
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080422/ae6a1ac3/attachment.html>
Gary Winiger wrote:
> I don't believe axyftp was proposed for the ON consolidation.
Found in the 1-pager in LSARC/2008/271/20080422_charles.baker:
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
> > Seriously. If we don't ever intend to put any engineering effort
> > into these things to make them work [at all, better, as expected]
> > on OpenSolaris, we shouldn't be mixing them into the core OS source
> > tree (aka the ON consolidation)!
>
> I don't believe axyftp was proposed for
> Gary Winiger wrote:
> > Why should it be part of the single Solaris bucket?
>
> Maybe this (and the other "Comay-List" cases) should simply
> be targeting the CompanionCD Consolidation, and we can simply
> have one mondo-case that says "this list of 500 cases goes
> there, where we expect to ha
On Tue, 2008-04-22 at 17:23 -0600, Mark A. Carlson wrote:
> Gary,
>
> I know there is an outstanding issue with the value of including all this
> FOSS stuff with minimal resources to adapt to our environment. But this case
> doesn't seem to be any more egregious than others. Fighting the busines
Darren J Moffat wrote:
> Charles Baker wrote:
>
>> The axyftp GUI allows the user to save the "jumbled" password. The
>> "jumbled" password
>> is saved in a ~/.axyftp directory. The file containing the jumbled
>> password has permissions
>> set to 600. This project includes only an inbound OS
Gary Winiger wrote:
> Why should it be part of the single Solaris bucket?
Maybe this (and the other "Comay-List" cases) should simply
be targeting the CompanionCD Consolidation, and we can simply
have one mondo-case that says "this list of 500 cases goes
there, where we expect to have architectur
ords? Why shouldn't it be using a keychain?
>
The axyftp GUI allows the user to save the "jumbled" password. The
"jumbled" password
is saved in a ~/.axyftp directory. The file containing the jumbled
password has permissions
set to 600. This project includes only an inbound OSR at this time.
> Gary..
> ___
> opensolaris-arc mailing list
> opensolaris-arc at opensolaris.org
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080422/58d20315/attachment.html>
]> >> The axyftp GUI allows the user to save the "jumbled" password. The
> >> "jumbled" password
> >> is saved in a ~/.axyftp directory. The file containing the jumbled
> >> password has permissions
> >> set to 600. This project includes only an inbound OSR at this time.
> >
> > What is the a
Gary Winiger wrote:
Our manpages should certainly include these URLs. It'd be nice if we
could also include a copy in /usr/share/doc/librsync/, but you'd need to
make sure that we can actually deliver those docs (i.e., that their
copyright license allows it or that we get permi
--On Tuesday, April 22, 2008 11:54:19 AM +0200 J?rg Barfurth
wrote:
>> I don't buy this "best compatibility" note. LinuxPAM fully supports
>> PAM_IGNORE.
True.
> But it appears to have interactions between pam_authenticate processing
> and pam_setcred processing not seen in Solaris PAM. The o
> >> Our manpages should certainly include these URLs. It'd be nice if we
> >> could also include a copy in /usr/share/doc/librsync/, but you'd need to
> >> make sure that we can actually deliver those docs (i.e., that their
> >> copyright license allows it or that we get permission from the autho
> I am sending the updated spec with respect to Gary's issue.
I'm still confused on how changing the size of structures
is mitigated in a patch release. What am I misunderstanding?
Further I don't see any expression of the interface stability
in the updated spec.
Feel free to accost said mangler when he returns O:-)
>>> I'm not sure what the reasons are, or if they really matter
>>> unless the architecture is wrong and then I'd leave that up
>>> to the Case Owner and the Case Submitter to work out before
>>> submitting the Fas
> >> Feel free to accost said mangler when he returns O:-)
> >>
> >
> > I'm not sure what the reasons are, or if they really matter
> > unless the architecture is wrong and then I'd leave that up
> > to the Case Owner and the Case Submitter to work out before
> > submitting the
Nicolas Williams schrieb:
> On Mon, Apr 21, 2008 at 02:06:52PM -0700, Darren J Moffat wrote:
>> Implementation Notes
>>
>> The module only supports the auth stack. pam_sm_setcred(3PAM) returns
>> the same value as pam_sm_authenticate(3PAM) returned or PAM_SUCCESS
>> if pam_sm_s
I am sponsoring this case for Charles Baker and marking it closed
approved automatic based on the FOSS checklist in the case directory.
-- mark
Mark Carlson wrote:
> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
> This information is Copyright 2008 Sun Microsystems
> 1. Introduction
>
Hi,
Darren J Moffat schrieb:
[...]
> Implementation Notes
>
> The module only supports the auth stack.
>
This isn't consistent with the 'upstream documentation' section:
> --- Upstream Documentation ---
>
[...]
> ...
> auth sufficient /lib/security/pam_radius_auth
I'm sponsoring this case for Pradhap Devarajan. The timer is set to
4/30/2008.
This case is to integrate rdiff-backup into Solaris, and requests micro
release binding. A man page, FAQ html and examples html are in the case
directory.
- Dan
Template Version: @(#)onepager.txt 1.35 07/11/07 S
> 3. Auditing: hald should be the right place to implement auditing
> For details for answers, please see the mails from Simon.
The important point for audit relative to this case is that
the GUI runs with the logined in users complete context.
VIZ, the process calling DBU
Using the check list as the project definition seems to be lacking.
Is there no documentation that describes what's being proposed?
Manual Pages
/usr/share/man/man1/axyftp.1
Minimally I'd expect to find this in the case directory.
Help Documen
All,
Not sure if this is the right group to post this question but if any one can
provide information that would be great..
Our concern is why should pkgadd/patch add use tmp space while installing
packages and patches this copy will happen even though the patches are
uncompressed and exist on loc
On Tue, Apr 22, 2008 at 11:54:19AM +0200, J?rg Barfurth wrote:
> > I don't buy this "best compatibility" note. LinuxPAM fully supports
> > PAM_IGNORE.
>
> But it appears to have interactions between pam_authenticate processing
> and pam_setcred processing not seen in Solaris PAM. The one I recal
30 matches
Mail list logo
