Re: [ANNOUNCEMENT] Updated [experimental]: bash-3.1-7

> > That is being set by cygcheck, just before invoking external programs.  It 
> > probably had something to do with forcing external programs to not rearrange 
> > option arguments (for example, "ls foo --all" treats --all as an option, 
> > but "POSIXLY_CORRECT=1 ls foo --all" treats --all as a filename).  But I think 
> > it is possible to get along without doing it (repeating the example, "ls -- 
> > foo --all" treats --all as a filename), and I personally think that cygcheck 
> > should be patched to QUIT setting POSIXLY_CORRECT, so that we can tell the 
> > masochists apart from normal users.
> 
> Ah, ok, so seeing it in cygcheck is a false positive. Didn't think that 
> cygcheck would tinker with my environment (maybe it should know it is 
> doing so and preserve the invocation value and print that?), so I didn't 
> think to actually 'echo $POSIXLY_CORRECT'. 
> 

2006-09-11  Eric Blake  <ebb9 <at> byu.net>

	* cygcheck.cc (main): Restore POSIXLY_CORRECT before displaying
	user's environment.

Re: [ANNOUNCEMENT] Updated [experimental]: bash-3.1-7

On Tue, Sep 12, 2006 at 12:05:06PM +0000, Eric Blake wrote:
>> > That is being set by cygcheck, just before invoking external programs.  It 
>> > probably had something to do with forcing external programs to not rearrange 
>> > option arguments (for example, "ls foo --all" treats --all as an option, 
>> > but "POSIXLY_CORRECT=1 ls foo --all" treats --all as a filename).  But I think 
>> > it is possible to get along without doing it (repeating the example, "ls -- 
>> > foo --all" treats --all as a filename), and I personally think that cygcheck 
>> > should be patched to QUIT setting POSIXLY_CORRECT, so that we can tell the 
>> > masochists apart from normal users.
>> 
>> Ah, ok, so seeing it in cygcheck is a false positive. Didn't think that 
>> cygcheck would tinker with my environment (maybe it should know it is 
>> doing so and preserve the invocation value and print that?), so I didn't 
>> think to actually 'echo $POSIXLY_CORRECT'. 
>> 
>
>2006-09-11  Eric Blake  <ebb9 <at> byu.net>
>
>	* cygcheck.cc (main): Restore POSIXLY_CORRECT before displaying
>	user's environment.

Applied.

Thanks, Eric.

cgf

Re: [ANNOUNCEMENT] Updated [experimental]: bash-3.1-7

According to Christopher Faylor on 9/12/2006 9:15 AM:
>> 2006-09-11  Eric Blake  <ebb9 <at> byu.net>
>>
>> 	* cygcheck.cc (main): Restore POSIXLY_CORRECT before displaying
>> 	user's environment.
> 
> Applied.

Not quite.  The changelog changed, but cygcheck.cc is still pending :)
http://cygwin.com/ml/cygwin-cvs/2006-q3/msg00158.html

--
Life is short - so eat dessert first!

Eric Blake             ebb9 <at> byu.net

Re: [ANNOUNCEMENT] Updated [experimental]: bash-3.1-7

On Wed, Sep 13, 2006 at 06:57:15AM -0600, Eric Blake wrote:
>According to Christopher Faylor on 9/12/2006 9:15 AM:
>>> 2006-09-11  Eric Blake  <ebb9 <at> byu.net>
>>>
>>> 	* cygcheck.cc (main): Restore POSIXLY_CORRECT before displaying
>>> 	user's environment.
>> 
>> Applied.
>
>Not quite.  The changelog changed, but cygcheck.cc is still pending :)
>http://cygwin.com/ml/cygwin-cvs/2006-q3/msg00158.html

Oops.  I got sidetracked with fixing the Makefile and forgot to actually
apply the patch.  Pretty stupid.

It is applied now.

cgf

[PATCH] add CRYPTPROTECT definitions to w32api's wincrypt.h

I am needing CRYPTPROTECT definitions in wincrypt.h and have attached a 
patch to add them.

Regards,

-Matthias Miller

--- wincrypt.h.orig	Thu Sep 14 04:19:36 2006
+++ wincrypt.h	Thu Sep 14 04:20:37 2006
 <at>  <at>  -371,6 +371,21  <at>  <at> 
 #define SCHANNEL_MAC_KEY    0x00000000
 #define SCHANNEL_ENC_KEY    0x00000001
 #define INTERNATIONAL_USAGE 0x00000001
+#define CRYPTPROTECT_DEFAULT_PROVIDER   { 0xdf9d8cd0, 0x1501, 0x11d1, {0x8c, 0x7a, 0x00, 0xc0, 0x4f,
0xc2, 0x97, 0xeb} }
+#define CRYPTPROTECT_PROMPT_ON_UNPROTECT     0x1
+#define CRYPTPROTECT_PROMPT_ON_PROTECT       0x2
+#define CRYPTPROTECT_PROMPT_RESERVED         0x04
+#define CRYPTPROTECT_PROMPT_STRONG           0x08
+#define CRYPTPROTECT_PROMPT_REQUIRE_STRONG   0x10
+#define CRYPTPROTECT_UI_FORBIDDEN        0x1
+#define CRYPTPROTECT_LOCAL_MACHINE       0x4
+#define CRYPTPROTECT_CRED_SYNC           0x8
+#define CRYPTPROTECT_AUDIT              0x10
+#define CRYPTPROTECT_NO_RECOVERY        0x20
+#define CRYPTPROTECT_VERIFY_PROTECTION  0x40
+#define CRYPTPROTECT_CRED_REGENERATE    0x80
+#define CRYPTPROTECT_FIRST_RESERVED_FLAGVAL    0x0FFFFFFF
+#define CRYPTPROTECT_LAST_RESERVED_FLAGVAL     0xFFFFFFFF

Re: [PATCH] cygcheck: follow symbolic links

On Mon, 24 Jul 2006, Corinna Vinschen wrote:

> On Jul 21 20:52, Igor Peshansky wrote:
> > In any case, here's the latest incarnation, with get_word and get_dword
> > folded into path.cc, and display_error returned to cygcheck.cc, where it
> > belongs.  Tested reasonably well (with symlinks pointing to symlinks,
> > etc).  I'll let you judge the neatness of the ChangeLog entry.  If I'm
> > lucky, this might just get into 1.5.21[*].
> > 	Igor
> > [*] Corinna, I'm guessing this is sufficiently different that you can't
> > accept it without "the fax" -- I'll keep pinging the guy who's holding
> > this up, but this message is also supposed to confirm that there is a
> > working patch, and the delay is simply bureaucratic.  Oh, the
> > frustration...  If you judge the changes from the previous incarnation
> > to not be significant, just go ahead and apply this, given the previous
> > approval.
>
> The latest fax was about this change, so I think this should still be
> covered, shouldn't it?  Ping the guy nevertheless.  We should stay on
> the safe side in legal questions.
>
> I'd be happy to apply the patch, but it would be nice if you could tweak
> the formatting somewhat:
>
> > +  if (GetLastError () != NO_ERROR) display_error ("get_dword");
>
> The display_error call should be on its own line, as usual.  This
> happens multiple times in your patch.
>
> > +  if (is_exe (fh))