Quality Management in Turkey

Yesterday I joined to a “literally” meeting with quality manager of one of the largest companies in defense industry. From my perspective, it went quite productive and revealing that I learned a lot. Plus, he offered me a position!! Yikes!! Anyway, it was very disappointing for me to face one of the decision makers of this defense company never heard of Common Criteria and compared CMM and alike with bullshit and introduced us his way of handling quality management over Microsoft Office tools. Actually he couldn’t, because it was hard him to find some policies and procedures through search files and folders over his mind. I know you are a busy man; that is normal, but you just have to admit you cant do it all by yourself. It was, in your time, you had to do it all by yourself; but your time has passed long ago sir. Now it is an age of reuse more than ever. There are numerous details that stabbed “engineering” from heart yesterday, which I cannot even write here; but I had my lesson learned: I need to work more than ever!

CTF_v6 ve teşekkürler..

BizNet sponsorluğunda Web Güvenlik Topluluğu tarafından gerçekleştirilen CTFv6 sonucunda kazandığım ödülü almak üzere geçtiğimiz Cuma günü BizNet’teydim ve sırasıyla Levent Bey, Haluk Bey ve Neşe Hanım’la tanışma ve kısa da olsa samimi bir sohbet imkanı buldum. Bu sıcak evsahipliğinden dolayı BizNet ailesine teşekkür ediyorum. Ayrıca, süreç boyunca ilgisini eksik etmeyen BizNet İstanbul ekibinden Deniz Bey’e; Web Güvenlik Topluluğu’ndan yeni tanıştığım ama sanki yıllardır tanıyormuş gibi hissettiğim Bünyamin Demir ve Onur Yılmaz’a ve tabi ki Bedirhan’a da teşekkürler.

Paranoid Security Tips

Well, the very built-in password boxes in application development  of any kind reveals the password length so should be avoided. It is really a security vs. usability issue; thanks to something I don’t know; we are not that paranoid and we favor usability on this one!

Episode.00 Be careful what you assume..

Assumptions is one of the main sections when writing a Security Target for a product in Common Criteria evaluation; a life-saving section indeed, otherwise none of the products would be certificated since you, the developer(yes, I am not), cannot control every single detail in a product’s running environment. This is when assumptions come in handy; do the assumption, get rid of handling the error, exception, threat whatever you are trying to handle. Moreover, if you literally assume that everything is going to be all right; that’s it! You don’t have to implement any more functions to make your product more secure, since everything is “literally” under control!
Unfortunately that is generally not what happens in real life, where there is always an Eve trying to harm either Alice or Bob or even both. In reality, regardless of us being 100% aware or not, assumptions takes great place in the development environment from “user inputs 6-digit password” to “unsigned int would be more than enough”; which are assumed for real audience of the product behaving in manners!
Taking under control of everything (possible) would be much more comforting than assuming something is (never) going to happen. Because it will; sooner or later; someone, malicious or not, will find a way to abuse the product and consequences could be devastating compared to cost it takes to actually control the case in the first place.
Long story short, aim of this post is to stress, as many of its successors will be, do not make any assumptions, if you can take things under control. “Beware of assumptions! Whatever you assume to be possible or impossible will have a tendency to become real for you!”
--
This post is supposed to be pilot of a new-old series called “Secure Coding Strikes Back!” aired here every week with season premiere “Who smashed my stack?” coming up next!

Initialized vs. Loaded

Today, I was implementing a simple user control UC, in WPF, that is composed of a CheckBox and a TextBox. I bound CheckBox's Content property to UC's Title property as;

   1: <CheckBox x:Name="chkTitle" 

   2:              Content="{Binding Title}" 

   3:              Height="30" />

It all worked well, until I came to a point where I have to set DataContext to of the UC to itself. Of course this is not much of a problem; since Bindings are updated through OnPropertyChanged method I overloaded and called from setters. The problem was, I encountered with two different events (when I follow the event option); Initialized and Loaded, that UserControl fires seperately for not a very apparent reason, apparently.

This subtle difference triggered me to google up the point with the title of this post as keywords; and I should have been feeling lucky to hit Mike Hillberg's post on the subject ( try it yourself ).

Those who are lazy enough not to read Mike's post should probably follow his words of wisdom:
"If you’re not sure which event to use, and you don’t want to read any more, use the Loaded event; it’s more often the right choice".

Mike has explained the difference of the events from a Layout perspective in his blog; and I will give an example from a Binding perspective.

   1: <TextBlock x:Name="txtPrice" Width="100"

   2:               Initialized="txtPrice_Initialized"

   3:               Loaded="txtPrice_Loaded"

   4:               >

   5:     <TextBlock.Text>

   6:         <Binding ElementName="cmbFruits" 

   7:                  Path="SelectedValue" />

   8:     </TextBlock.Text>

   9: </TextBlock>

  10:             

  11: <ComboBox   x:Name="cmbFruits" 

  12:             ItemsSource="{Binding Fruits}"

  13:             DisplayMemberPath="Name" 

  14:             SelectedValuePath="Price"

  15:             SelectedIndex="0"

  16:             />

In the above code snippet, TextBlock’s Text property is bound to the SelectedValue property of ComboBox. TextBlock’s both Initialized and Loaded events are handled in the codebehind.

When I debug the application, and step into Initialized event handler; TextBlock’s Text property is equal to Empty string; since by the time it is initialized, its data provider, cmbFruits; has not yet been initialized ( as it comes latter in the xaml code).  But when I step into TextBlock’s Loaded event handler; I see that its Text property is set to the selected Fruit’s price; because at that time, cmbFruits is initialized as SelectedIndex = 0.

In my example, the events are fired as the following order:

• TextBlock is initialized.
• ComboBox is initialized.
• Window is initialized.
• Window is loaded.
• TextBlock is loaded.
• ComboBox is loaded.

I dont want to be repeating Mike, so I am not going to explain the order; if you are curious about it, you should read his post.

Hope it helps for a why question. Enjoy.