What is Windows registry key for password history?

Question

I'm trying to port our build system from make to CMake, and I encountered a problem that surprisingly not "Googleable" Our code is C++ 11/14, compiles fine with GCC6.2, the make applies zillion switches when invoking GCC, mostly pedantic warnings. I built a CMake system that compiles (GCC 6.3) most of the code without a problem but some modules failed to build because of the following

flexible array member ‘blahblah’ not at end of ‘struct‘

Aside why it appears in the C++ code. Why did it compile in the make based system? AFAIK, flexible array is not a part of C++ standard. GCC specific extension? What command line switch controls FAM behavior? How do I make it compile as it did in the original make system?

In case someone needs a snippet of compiled code

struct Foo
{
    int _10;
    double _20;
    int a[];
};

struct Bar
{
    Foo foo;
    double _1;
    int _2;
}

To add more context, the cmake file

cmake_minimum_required(VERSION 3.9)

project(foo VERSION ${FOO_VERSION} DESCRIPTION "foo")

set(CMAKE_CXX_STANDARD 14)

set(CMAKE_C_STANDARD 99)

add_executable(foo foo.cpp foo_backup.cpp main.cpp)

set_target_properties(foo PROPERTIES VERSION ${PROJECT_VERSION})

target_include_directories(foo PUBLIC ${CMAKE_SOURCE_DIR}/lib/include ${CMAKE_SOURCE_DIR}/lib/include/bar)

Solution 1

HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 

Value to check: RefusePasswordChange and MaximumPasswordAge

[Source: MS Technet Librairy]

Solution 2

I don't know about Windows XP/2003, but on Windows 7 Ultimate x64 it's apparently

Key:         HKLM\SAM\SAM\Domains\Account
Value:       F
Byte offset: 0x10   (0x3A corresponds to 0, 0x3B corresponds to 1)

It's in binary, maintained by LSASS, so I don't recommend you try to change it through undocumented means.

Comments

[Fran Fitzpatrick]

Determines the number of unique new passwords that have to be associated with a user account before an old password can be reused. microsoft.com/resources/documentation/windows/xp/all/proddoc‌​s/…

[Ken White]

There is no "password history" registry key. If there was, it would be a major security hole. @Fran: That's password policy, not password history.

[Fran Fitzpatrick]

How would it be a major security hole? Every other password policy option is linked to a registry key.

[Fran Fitzpatrick]

It is a password policy to enforce password history. Ah, lets just chalk it up to semantics. :-) Anyone know?

[Admin]

Suggestion: dump the entire registry to e.g. text or xml, change the "password policy", dump the registry again, then compare the two dumps with e.g. the linux diff tool (I haven't used windows in years so I don't know how easy it is to get registry dumps.)

[cutrightjm]

If you're looking for current or old passwords, they're not stored in the registry. The only things that would be found in the registry are restrictions for setting a ne password.

[underscore_d]

Surely, ff you are asking people what might differ between the build files to cause this, you need to post the build files...

[Mat]

Don't vary two things at once (your compiler and your build system). Get your cmake stuff to work with the "known good" compiler version, then change the compiler - or the other way around. Also, why don't you just copy the "zillion" flags?

[Vroomfondel]

Flexible array members appear in C99 - any chance that some of your files are compiled as C instead of C++ sources?

[kreuzerkrieg]

@Mat, zillion flags dispersed over 60kb of make file with quadrillion ifs. so a) its quite complicated to figure out what is the final set of switches applied to the compilation b) I have a feeling that we dont need most of them, they are there mostly because of historical reasons

[kreuzerkrieg]

@underscore_d do you think it could be 6.2->6.3 difference?

[Mat]

@kreuzerkrieg: ... and yet your code no longer builds. Again, don't change both your build system and your compiler at the same time. Right now, you don't know what's to blame.

[kreuzerkrieg]

@Vroomfondel I saw this flag applied in our make -std=c99, but this is cpp file with actual cpp file, I think C compiler wouldnt compile CPP code, right?

[UKMonkey]

I'd go with that your make file used a C compiler and CMake is using a C++ compiler - but who can say. Why not try comparing the actual commands run?

[kreuzerkrieg]

@UKMonkey check my answer to Vroomfondel

[UKMonkey]

You've not posted what commands are actually used - so it's not worth postulating if they'll compile it or not

[kreuzerkrieg]

@UKMonkey, before I will find how to retrieve actual parameters used on each compilation, in theory, what compiler should be able to accept FAM construct? C? C99? C++? Which one?

[UKMonkey]

Compilers are only required to implement what is in the standard. There's nothing saying that they're not allowed to add more. This is where compiler extensions comes in, and "Undefined Behavour". It's like asking which compilers can I not return a value in a function for ... ., not doing so is undefined, so some might error, some might warn, and others might open a black hole.

[Vroomfondel]

Would you deem it possible to rewrite your build to a "tabular" build config approach? Imagine a small scale relational database (or just a few tables) where you select the appropriate properties and elements instead of if-else chains? Would that make your build simpler/clearer without going to CMake?

[kreuzerkrieg]

@Vroomfondel I'm going to the CMake since it is more convenient build system, make is soooo seventies :)

[Vroomfondel]

In embedded environments CMake doesn't cut it either. Way to focused on "big" systems IMHO.

[Vroomfondel]

Have a look at the answer in this question to give you a feel what can be done with pure make in terms of build configuration. The question is if the new syntax of CMake or whatever is really so much simpler in the face of the cost of adding one more tool and level of indirection.

[kreuzerkrieg]

I think it begins to be "religious" issue, I believe in make, I dont believe in make, etc. From my point of view there is no reason to use make files directly in the year 2018. Go maintain make configurations for 10 distros of 4 OSes...

[kreuzerkrieg]

Yep, you are right, I've already found it using godbolt.org The 6.2 compiles my code, 6.3 and later will complain. I have a feeling we will have to fix it if we want to get modern compiler